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

On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:

I think "the guy" may be git itself. For example, here is a possible session with jc/pull-training-wheel:

  $ git push
  To ...
   ! [rejected]        master -> master (non-fast-forward)
  error: failed to push some refs to '...'
  hint: Updates were rejected because the tip of your current branch is behind
  hint: its remote counterpart. Integrate the remote changes (e.g.
  hint: 'git pull ...') before pushing again.
  hint: See the 'Note about fast-forwards' in 'git push --help' for details.

  $ git pull
  The pull does not fast-forward; please specify
  if you want to merge or rebase.

  Use either

      git pull --rebase
      git pull --merge

  You can also use 'git config pull.rebase true' (if you want --rebase) or
  'git config pull.rebase false' (if you want --merge) to set this once for
  this project and forget about it.

The user is pointed at "pull" from "push", and then gets presented with the "merge or rebase" choice. It may be that the advice you can find by googling "merge vs rebase" is enough to then help the person along (and/or we may need to improve the manpages in that respect).

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).

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.

A deprecation message helps people who are making the transition from an older behavior to a newer one. It cannot help new users who start with a git version after the deprecation period.

I think that is what we have advice.* for.

-Peff