

Git: fetch and merge, don’t pull - eplanit
http://longair.net/blog/2009/04/16/git-fetch-and-merge/

======
justin_vanw
I don't quite follow what he is trying to say.

From the manpage for git pull: git-pull - Fetch from and merge with another
repository or a local branch

Git pull is identical to git fetch && git merge $remote_branch. He's saying
that it prevents you from learning how branching works. So, if he were
explicit, he should say 'Don't use git until you know how branching works at
some level.', which is good advice. Not using git pull is a pretty sensational
way to get at that nugget.

~~~
masklinn
His issues seem to be mostly:

* If you `git pull`, you don't get the chance to diff between your local branch and what you just fetched and check if you really want to do that merge, using `git fetch` and `git merge` makes it more likely you'll do that check

* Getting used to `git fetch` means if you need to diverge from the straight `git fetch; git merge` workflow (because you want to rebase, or you have a high number of active topic branches floating around) you're already halfway there.

------
viraptor
Very nice description of a number of use cases. I was just a bit annoyed that
the title was described in a very hand-waving way (do it because it's more
useful sometimes). With so many other examples I really expected a detailed
description of some situation where fetch/pull makes a huge difference.

------
natesm
No mention of "git pull --rebase"?

~~~
stock_toaster
I like it so much, I even have `autosetuprebase = remote` in my gitconfig.

~~~
chousuke
I don't think that's a good idea in general. It might work for your particular
use case, but if you're doing work on a branch you regularly update from a
remote, then you will also need to test every time you do a pull. you might
introduce new bugs because the code you rebased does not necessarily make
sense on top of the new base, and you have no easy way to reset to the old
base either. Merges can be undone easily but rebases are much trickier.

I think the best approach is to code on a separate branch while keeping the
base unchanged and do the rebase (or merge) when the code is complete. That
way, you at least have a branch of code that you know is working, and when you
merge, you immediately know that any issues are caused by something that
changed between the old and the new base. And you still can do mid-development
rebases if there is a need for them.

~~~
fpgeek
I think you're missing the point. Rebasing work you haven't pushed
_disentangles_ your work from the remote branch.

Here are some advantages:

1\. Work you happened to do after a merge doesn't spuriously appear to depend
on that merge.

2\. You can do conflict resolution incrementally during the rebasing process
(commit-by-commit instead resolving a merge conflict all at once).

3\. Linearizing more of your history improves the precision of git bisect.
You're much more likely to have the result of a bisect point to a simple
commit rather than a complex merge when there are fewer merges.

The two major disadvantages I see are:

1\. Pulling and rebasing is more complex than pulling and merging (more steps
and more decisions).

2\. You have to be careful not to rebase a branch you have "published".

~~~
chousuke
This reply is a bit late but...

You're not supposed to do work on the same feature after a merge. I'm not
advocating pulling master (or whatever the base branch is) often and merging
whenever, so that you end up with loads of pointless merges. Once your feature
is done, you merge once. This makes point 3 pretty much moot, since bisect
handles merges just fine.

Sometimes you need to update your code on top of a new base because of some
important bugfix or something, and then it's fine to rebase, but I don't think
it should be the default.

I'll accept point 2, though I think git's merging is good enough that it's not
noticeable in most cases. If you rebase you also lose information about the
conflicts which may be undesirable. Someone might want to review your merge to
see if you have solved the conflicts correctly.

------
yason
Not sure if it warrants an article but I've never found any use for git-pull
either. When I want to fetch and merge/rebase, I can _do just that_ ; I never
figured why would I want to use git-pull for it. But on the other hand, I've
only used git for about five years and I've only learned the most important
low-level commands yet.

------
adamjernst
This is one of the things that Mercurial got right. (In Mercurial, you pull
and then merge separately, usually.)

------
anandpdoshi
git is deep. And you can do the same thing using different steps and different
number of steps. I think this post provided a good tip on how to go about
merging remote changes into your local. If one finds that git pull requires a
lot of cleanup activity, git fetch and git merge is a good way to go..

------
ZoFreX
Interesting to learn. In Mercurial (which is what I use primarily) pull does
not merge unless you ask it to. Is there a list anywhere of gotchas in git for
people coming from other DVCS? (i.e. things like commands with the same name
that do subtly different things, such as this)

~~~
masklinn
> In Mercurial (which is what I use primarily) pull does not merge unless you
> ask it to.

Actually, in Mercurial `pull` does not _ever_ merge. It can _update_ if you
ask it to (with `-u`), but it won't merge.

`hg fetch` (standard extension) can merge (it's basically "pull and update, if
update fails merge"), but it might go the way of the dodo pretty soon[0]

[0] [http://www.selenic.com/pipermail/mercurial-
devel/2011-August...](http://www.selenic.com/pipermail/mercurial-
devel/2011-August/033764.html)

~~~
ZoFreX
Mea culpa, absolutely correct.

------
mise
The article mentions:

    
    
        $ git fetch
        $ git checkout master
        $ git merge origin/master
    

On the third (last) line of code above, is there a more short-hand way to say
"merge the remote tracked branch related to this current branch"?

~~~
DrJ
git pull?

------
freedrull
Git pull is nice, but it _is_ good to know what's going on underneath the
hood.

