Git question

[Michael Alexeev]

Hi All,

i have novice git question. If I want to create a new branch locally (pullexec) do I need initially to

git fetch origin pullexec
git checkout -b pullexec

to create a branch and than

git checkout pullexec

to switch between branches. Or do I need to use

git branch pullexec origin/pullexec

The former seems to work. The latter doesn't:
mike@ubuntu:~/voltdb/voltdb$ git branch pullexec origin/pullexec
fatal: Not a valid object name: 'origin/pullexec'.

And after I created the branch using 'git fetch'
mike@ubuntu:~/voltdb/voltdb$ git branch pullexec origin/pullexec
fatal: A branch named 'pullexec' already exists.

One of the Stackoverflow posts recommends 'git branch' command to create a local version which track the remote one. Which is what I need but it didn't work for me for whatever reason. Is 'git fetch/checkout' sequence also the right way to go?

Thanks,
Mike







 

[Ning Shi]

Hi Michael,

> Is 'git fetch/checkout' sequence also the right way to go?

'git fetch origin' will fetch all branches and changes on github to your local machine.

To create a local branch that tracks the remote pullexec branch, you can use 'git checkout -b pullexec origin/pullexec'. If you already have a local 'pullexec' branch that doesn't track any remote branch, you can safely remove it by executing 'git branch -d pullexec'. Then you should be able to use the checkout command to do what you want.

--
Ning

[Michael Alexeev]

Hi Ning,

I am getting fatal error trying to checkout pullexec branch
mike@ubuntu:~/voltdb/voltdb$ git branch
* master
mike@ubuntu:~/voltdb/voltdb$ git checkout -b pullexec origin/pullexec
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/pullexec' which can not be resolved as commit?

i can't even see remote pullexec branch
mike@ubuntu:~/voltdb/voltdb$ git branch -r
  origin/ElClient
  origin/HEAD -> origin/master
  origin/eng1850-integration
  origin/eng2205-integration
  origin/eng2250-integration
  origin/eng2355-integration
  origin/export-it9-candidate
  origin/exportrefactor
  origin/fasttemptables
  origin/hsql2
  origin/johnrejoin
  origin/kv_txns
  origin/master
  origin/newstartup
  origin/portland
  origin/twophaseinit
  origin/voltdb-0.6
  origin/voltdb-0.9
  origin/voltdb-1.0
  origin/voltdb-1.1
  origin/voltdb-1.2
  origin/voltdb-1.2.1
  origin/voltdb-1.3
  origin/voltdb-1.3.3
  origin/voltdb-1.3.4
  origin/voltdb-1.3.6
  origin/wan-secondary
mike@ubuntu:~/voltdb/voltdb$

Of cause, it's accessible on github
https://github.com/VoltDB/voltdb/branches/pullexec

I can fetch this branch using 'git fetch origin pullexec' but it won't track remote branch though. 

Mike

[Ning Shi]

> I can fetch this branch using 'git fetch origin pullexec' but it won't track remote branch though.

If you 'git fetch origin', does pullexec show up in 'git branch -a'?

Ning

[Michael Alexeev]

Ning,
Yes, it does

mike@ubuntu:~/voltdb/voltdb$ git fetch origin
git-remote-https: /usr/local/lib/liblber-2.4.so.2: no version information available (required by /usr/lib/libcurl-gnutls.so.4)
git-remote-https: /usr/local/lib/libldap_r-2.4.so.2: no version information available (required by /usr/lib/libcurl-gnutls.so.4)
remote: Counting objects: 8431, done.
remote: Compressing objects: 100% (2600/2600), done.
remote: Total 7968 (delta 5736), reused 7040 (delta 4874)
Receiving objects: 100% (7968/7968), 11.03 MiB | 1.14 MiB/s, done.
Resolving deltas: 100% (5736/5736), completed with 368 local objects.
From https://github.com/VoltDB/voltdb
 * [new branch]      build-tests -> origin/build-tests
 * [new branch]      client_updates -> origin/client_updates
 * [new branch]      csv-loader -> origin/csv-loader
 * [new branch]      eng2551-integration -> origin/eng2551-integration
 * [new branch]      findbugs-fixes -> origin/findbugs-fixes
 * [new branch]      iv2-wip    -> origin/iv2-wip
 * [new branch]      jsonci     -> origin/jsonci
   f6adc60..c9eb599  master     -> origin/master
 * [new branch]      mp-init    -> origin/mp-init
 * [new branch]      mpxrunner  -> origin/mpxrunner
 * [new branch]      pullexec   -> origin/pullexec
 * [new branch]      sysproc-advert -> origin/sysproc-advert
 * [new branch]      voltcore-integration -> origin/voltcore-integration
 * [new branch]      voter_refactor -> origin/voter_refactor
 * [new tag]         voltdb-2.2.1 -> voltdb-2.2.1
 * [new tag]         voltdb-2.2.2 -> voltdb-2.2.2
 * [new tag]         voltdb-2.5 -> voltdb-2.5
mike@ubuntu:~/voltdb/voltdb$

mike@ubuntu:~/voltdb/voltdb$ git branch -a
* master
  remotes/origin/ElClient
  remotes/origin/HEAD -> origin/master
  remotes/origin/build-tests
  remotes/origin/client_updates
  remotes/origin/csv-loader
  remotes/origin/eng1850-integration
  remotes/origin/eng2205-integration
  remotes/origin/eng2250-integration
  remotes/origin/eng2355-integration
  remotes/origin/eng2551-integration
  remotes/origin/export-it9-candidate
  remotes/origin/exportrefactor
  remotes/origin/fasttemptables
  remotes/origin/findbugs-fixes
  remotes/origin/hsql2
  remotes/origin/iv2-wip
  remotes/origin/johnrejoin
  remotes/origin/jsonci
  remotes/origin/kv_txns
  remotes/origin/master
  remotes/origin/mp-init
  remotes/origin/mpxrunner
  remotes/origin/newstartup
  remotes/origin/portland
  remotes/origin/pullexec
  remotes/origin/sysproc-advert
  remotes/origin/twophaseinit
  remotes/origin/voltcore-integration
  remotes/origin/voltdb-0.6
  remotes/origin/voltdb-0.9
  remotes/origin/voltdb-1.0
  remotes/origin/voltdb-1.1
  remotes/origin/voltdb-1.2
  remotes/origin/voltdb-1.2.1
  remotes/origin/voltdb-1.3
  remotes/origin/voltdb-1.3.3
  remotes/origin/voltdb-1.3.4
  remotes/origin/voltdb-1.3.6
  remotes/origin/voter_refactor
  remotes/origin/wan-secondary

and  also in 'git branch -r'

mike@ubuntu:~/voltdb/voltdb$ git branch -r
  origin/ElClient
  origin/HEAD -> origin/master

  origin/build-tests
  origin/client_updates
  origin/csv-loader
  origin/eng1850-integration
  origin/eng2205-integration
  origin/eng2250-integration
  origin/eng2355-integration
  origin/eng2551-integration
  origin/export-it9-candidate
  origin/exportrefactor
  origin/fasttemptables
  origin/findbugs-fixes
  origin/hsql2
  origin/iv2-wip
  origin/johnrejoin
  origin/jsonci
  origin/kv_txns
  origin/master
  origin/mp-init
  origin/mpxrunner
  origin/newstartup
  origin/portland
  origin/pullexec
  origin/sysproc-advert
  origin/twophaseinit
  origin/voltcore-integration

  origin/voltdb-0.6
  origin/voltdb-0.9
  origin/voltdb-1.0
  origin/voltdb-1.1
  origin/voltdb-1.2
  origin/voltdb-1.2.1
  origin/voltdb-1.3
  origin/voltdb-1.3.3
  origin/voltdb-1.3.4
  origin/voltdb-1.3.6

  origin/voter_refactor
  origin/wan-secondary


Finally,

mike@ubuntu:~/voltdb/voltdb$ git checkout -b pullexec origin/pullexec

D    voltdb/.gitignore
Branch pullexec set up to track remote branch pullexec from origin.
Switched to a new branch 'pullexec'
mike@ubuntu:~/voltdb/voltdb$ git branch
  master
* pullexec


Looks like I am all set now. Thank you very much.

Mike

[Michael Alexeev]

The last step, I hope :)

Looks like I don't have permission to check-in

mike@ubuntu:~/voltdb/voltdb$ git branch
  master
* pullexec

mike@ubuntu:~/voltdb/voltdb$ git push
error: The requested URL returned error: 403 while accessing https://github.com/VoltDB/voltdb.git/info/refs

fatal: HTTP request failed

Mike

[Ning Shi]

Hi Michael,

> Looks like I don't have permission to check-in

It's because that repository is owned by VoltDB. You cannot write to a
Github repository that you don't have write access to.

You can fork our repository first by clicking the fork button near the
upper right corner of the VoltDB project page. Then you will have an
identical Volt repository that is owned by you. On your local machine,
you can clone the repository you just forked. Since this repository is
owned by you, you can do anything to it. All your commits will go to
your Github repository. Once you have a set of commits ready, you can
initiate a pull request for us to review.

http://help.github.com/fork-a-repo/

Ning

[Michael Alexeev]

Thanks Ning, that makes sense.

Paul, would this work for you? I assume you would be able to update this repository as well. 

Mike

[Paul Martel]

This makes sense (wish I'd thought of it). Based on this setup, there are actually a few options for how to proceed.
I briefly considered that it might be more convenient to manage the project entirely on your fork, but there are some
nice benefits to staging to an official VoltDB-owned branch -- our in-house integration testing tools are able to access it.

So, the way I imagine this flowing is that you will post commits to your forked github repo when ready.
I'm not sure if git/github will reward you for using a matching pullexec branch name in your repo when it comes time
to make the pull request, but it seems like it's worth a shot.  I can manage the VoltDB side of the pull request acceptance.
I'll also manage the eventual merge process back into the VoltDB master.  It's possible, but not likely that some critical commit will get made to master and the author will request that all active branches adopt it (like because it enables improvements to the common testing framework). I'll manage that, too -- it may require a judgment call whether to try to push such a change to your forked repo as well.

The remaining category of changes would be project-specific changes coming from VoltDB. If you wanted to maintain total control of your fork, I/we could push to the VoltDB pullexec branch and then make a pull request to your fork which you could then review and accept (fair is fair).

Otherwise, you'd have to grant me (for instance) write privileges to your repo so I could push commits directly. I don't know that I'd personally recommend that -- I have trouble enough now tracking the one shared github repo and too many private local repos and their (too many) branches -- maybe direct write access to yet another shared repo would just muddy the waters. On the other hand, maybe it would make it easier for me to isolate this project in particular -- it's hard to predict. Also, I'm a little curious to see how helpful github (vs. raw git) is when it comes to reconciling forks and generally managing round-trip development between github-hosted repos. Bottom line: if you feel that my using direct write access to your repo would make things much more convenient for you, I'm willing to give it a try.

In any case, if you send me a link to your github account/repo, I can at least follow it.

--paul

[Michael Alexeev]

Hi Paul,

On Sat, Apr 14, 2012 at 6:10 PM, Paul Martel <pma...@voltdb.com> wrote:

This makes sense (wish I'd thought of it). Based on this setup, there are actually a few options for how to proceed.
I briefly considered that it might be more convenient to manage the project entirely on your fork, but there are some
nice benefits to staging to an official VoltDB-owned branch -- our in-house integration testing tools are able to access it.

So, the way I imagine this flowing is that you will post commits to your forked github repo when ready.
I'm not sure if git/github will reward you for using a matching pullexec branch name in your repo when it comes time
to make the pull request, but it seems like it's worth a shot.  I can manage the VoltDB side of the pull request acceptance.
I'll also manage the eventual merge process back into the VoltDB master.  It's possible, but not likely that some critical commit will get made to master and the author will request that all active branches adopt it (like because it enables improvements to the common testing framework). I'll manage that, too -- it may require a judgment call whether to try to push such a change to your forked repo as well.

The remaining category of changes would be project-specific changes coming from VoltDB. If you wanted to maintain total control of your fork, I/we could push to the VoltDB pullexec branch and then make a pull request to your fork which you could then review and accept (fair is fair).

Otherwise, you'd have to grant me (for instance) write privileges to your repo so I could push commits directly. I don't know that I'd personally recommend that -- I have trouble enough now tracking the one shared github repo and too many private local repos and their (too many) branches -- maybe direct write access to yet another shared repo would just muddy the waters. On the other hand, maybe it would make it easier for me to isolate this project in particular -- it's hard to predict. Also, I'm a little curious to see how helpful github (vs. raw git) is when it comes to reconciling forks and generally managing round-trip development between github-hosted repos. Bottom line: if you feel that my using direct write access to your repo would make things much more convenient for you, I'm willing to give it a try.

In any case, if you send me a link to your github account/repo, I can at least follow it.

 
I am perfectly fine with this approach. I already forked the repository

https://alex...@github.com/alexeevm/voltdb.git

and I need your user id to add you as a collaborator.  The repo structure matches the VoltDB one and I am planning to use pullexec branch for the prototype per your advice.

Ning, thank you very much for helping me out with the git questions.

Mike