Re: [PATCH 0/3] Reject non-ff pulls by default

On 2013-09-04 18:59, Junio C Hamano wrote:

I'm a bit late to the discussion, but I wanted to chime in. I detest 'git pull' and discourage everyone I meet from using it. See: <http://stackoverflow.com/questions/15316601/why-is-git-pull-considered-harmful> for my reasons.

Instead, I encourage people to do this:

   git config --global alias.up '!git remote update -p; git merge
--ff-only @{u}'

and tell them to run 'git up' whenever they would be tempted to use a plain 'git pull'.

I usually work with a central repository with topic branches.  I follow
this rule of thumb:
  * When merging a "same-named" branch (e.g., origin/foo into foo, foo
    into origin/foo), it should always be a fast-forward.  This may
    require rebasing.
  * When merging a "differently-named" branch (e.g., feature.xyz into
    master), it should never be a fast-forward.

In distributed workflows, I think of 'git pull <collaborator-repo> <their-branch>' as merging a differently-named branch (I wouldn't be merging if they hadn't told me that a separate feature they were working on is complete), so I generally want the merge commit. But when I do a 'git pull' without extra arguments, I'm updating a same-named branch so I never want a merge.

When merging a differently-named branch, I prefer the merge --no-ff to be preceded by a rebase to get a nice, pretty graph:

       * merge feature.xyz  <- master
       |\
       | * xyz part 3/3
       | * xyz part 2/3
       | * xyz part 1/3
       |/
       * merge feature.foo
       |\
       | * foo part 2/2
       | * foo part 1/2
       |/
       * merge feature.bar
       |\
       ...

The explicit merge has several benefits:
  * It clearly communicates to others that the feature is done.
  * It makes it easier to revert the entire feature by reverting the
    merge if necessary.
  * It allows our continuous integration tool to skip over the
    work-in-progress commits and test only complete features.
  * It makes it easier to review the entire feature in one diff.
  * 'git log --first-parent' shows a high-level summary of the changes
    over time, while a normal 'git log' shows the details.

I stop and review what's going on, then make a decision:
  * usually it's a rebase
  * sometimes it's a rebase --onto (because the branch was
    force-updated to undo a particularly bad commit)
  * sometimes it's a rebase -p (because there's an explicit merge of a
    different branch that I want to keep)
  * sometimes it's a reset --hard (my changes were made obsolete by a
    different upstream change)
  * sometimes it's a merge
  * sometimes I do nothing.  This is a fairly regular pattern:  I'm in
    the middle of working on something that I know will conflict with
    some changes that were just pushed upstream, and I want to finish
    my changes before starting the rebase.  My collaborator contacts me
    and asks, "Would you take a look at the changes I just pushed?"  If
    I type 'git pull' out of habit to get the commits, then I'll make a
    mess of my work-in-progress work tree.  If I type 'git up' out of
    habit, then the merge --ff-only will fail as expected and I can
    quickly review the commits without messing with my work tree or
    HEAD.

Even if I always rebase or always merge, I want to briefly review what changed in the remote branch *before* I start the rebase. This helps me understand the conflicts I might encounter.

Thus, ff-only always works for me. I might have to type a second merge or rebase command, but that's OK -- it gives me an opportunity to think about what I want first. Non-ff merges are rare enough that the interruption isn't annoying at all.

My choice depends on the circumstances of the divergence. It's never as simple as branch X always has this policy while branch Y has that policy.

Habit/muscle memory/I'm tired and not thinking 100% clearly.

-Richard