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

On Sun, Sep 08, 2013 at 02:54:20AM -0400, Jeff King wrote:

I am genuinely curious what people in favor of this feature would want
to say in the documentation to a user encountering this choice for the
first time. In my experience, rebasing introduces more complications,
specifically:

  1. the merge is "backwards" with respect to ours/theirs

  2. you may end up with difficult conflict resolution due to repeated
     changes over the same section of code. E.g., you write some buggy
     code and then fix it, but upstream has changed the same area.
     Rebasing involves first resolving your buggy version with the
     upstream code, and then resolving the fix on top of the previous
     resolution.

  3. rewriting of commits found in other branches, which then need
     rebased on top of the branch you just rebased

  4. a previously bug-free commit can show a bug after the rebase if
     other parts of the project changed (whereas with a merge, the bug
     would be attributable to the merge)

I know those are all balanced by some advantages of rebasing, but I also
think they are things that can be troublesome for a user who does not
fully grok the rebase process. I'm just wondering if we should mention
both, but steer people towards merging as the safer alternative (you
might have ugly history, but you are less likely to create a mess with
duplicate commits or badly-resolved conflicts).

The really correct thing to do here is to encourage a feature branch
workflow, but in my experience people are happier to walk through a
rebase than to switch over to feature branches completely.

An alternative pull mode would be:

    git reset --keep @{u} &&
    git merge @{-1}

which gets a sensible history shape without any of your disadvantages
above.  But that didn't go anywhere last time it came up [1] [2].

[1] http://article.gmane.org/gmane.comp.version-control.git/210246
[2] http://article.gmane.org/gmane.comp.version-control.git/210625

quoted

Fortunately there probably are very few of these users.

Maybe. I am not sure how one would measure.

If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most frequently, what kinds of workflows they tend to
see, etc. Their experience may be biased towards corporate-ish users,
though, because those are the people who pay for training.

I expect corporate environments are the ones in which this is relevant.
Open source projects that care about the shape of history can have one
person able to write to the central repository who can enforce the
policy they want.  This tends to be more difficult in a corporate
environment, particularly one that was previously using a centralised
VCS.