Comments on: git: fetch and merge, don’t pull

By: Cyrus Master

Cyrus Master — Mon, 26 Apr 2010 08:42:25 +0000

Fantastic article. Thanks!

By: Jason Wagner

Jason Wagner — Thu, 04 Mar 2010 06:22:56 +0000

Excellent post! Thanks so much for taking the time to write this up, it has helped a lot. I’m pretty comfortable with SVN and some other proprietary SCM’s.. but i’m just learning Git. Some of the principals are quite tricky! :p

By: chhh

chhh — Mon, 04 Jan 2010 19:59:27 +0000

Well, it’s your article, so you decide.
Usually i just scan through pages when searching for solution, but read this whole text.

Yes “git merge origin/master” part may become confusing for many people who are only beginning using git. In my opinion it would have been very helpful if you had mentioned ways to get out of merge conflicts (not in full blown detail, just brief directions like git reset –merge/hard HEAD or something)

By: mark

mark — Sun, 03 Jan 2010 12:04:15 +0000

Thanks for your comment, chhh. Do you mean something like the bit where I talk about doing “git merge origin/master”? I suppose it could go into more detail about the different options for doing that (e.g. “git reset –hard origin/master” to throw away your changes, “git rebase”, etc.) for various situations, but I’m a bit worried that the post is already overlong.

By: chhh

chhh — Fri, 18 Dec 2009 22:28:27 +0000

a very useful and descriptive post, thank you
the only thing missing, in my opinion, is an example of of updating a local -track branch with a remote tracking one.

By: mark

mark — Wed, 04 Nov 2009 12:01:48 +0000

I don’t think there’s a single command that will do that. You’d have to be quite careful about writing such a script, since you would need to safely checkout each branch (i.e. check that the working tree is clean before you switch) and check that the merge will be a fast-forward.

I can’t really imagine wanting to do that, myself, because in practice the warning you get on checking out a branch (i.e. the one about the state of that branch with regard to the remote-tracking branch it tracks) stops me from forgetting to merge before carrying on work.

By: alexandrul

alexandrul — Wed, 04 Nov 2009 11:20:42 +0000

In the first place, thank you for the article.

As a side question, after a fetch, how can I merge all tracked remote branches with the local ones in a single command? (besides creating a script to merge each branch in turn)

By: mark

mark — Wed, 22 Apr 2009 15:23:25 +0000

Sitaram: thanks for bringing that to my attention. I’ve just tested on one of the systems I use which still has git 1.5.3.5 and it does give an error in that case:
$ git push origin topic:topic-new error: dst refspec topic-new does not match any existing ref on the remote and does not start with refs/. fatal: The remote end hung up unexpectedly error: failed to push to '/home/mark/tmp/foo/.git'
… but the same test on git 1.6.1.2 works OK:
$ git push origin topic:new-topic Total 0 (delta 0), reused 0 (delta 0) To /home/mark/tmp/quuz/ * [new branch] topic -> new-topic
At least I wasn’t just making it up :) I’ll update the post with a note that that only applies to older versions.

By: Sitaram

Sitaram — Wed, 22 Apr 2009 13:40:41 +0000

inside the little breakout box starting with “aside…”, it says:

… or if “experiment-by-bob” doesn’t already exist, the syntax needs to be:

git push origin experimental:refs/heads/experiment-by-bob

I have just tested it and it is not necessary; I can make a brand new branch and push it to a *different* new name to origin without needing that “refs/heads” part.

This is on Git 1.6.2; I did not check older versions but I do not remember ever having to do this.

By: mark

mark — Tue, 21 Apr 2009 13:30:34 +0000

Deskin: thanks, and thank-you for catching that error; I’ve corrected the appropriate bits.