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
> > 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html