On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote: > > I think it's fine to tell them to do "git pull --merge". What I'd worry > > more about is somebody who is suddenly presented with the choice between > > "--rebase" and "--merge" and doesn't know which to choose. We've created a > > cognitive load on the user, and even more load if they choose --rebase > > and don't quite understand what it means. > > If that happens they will go back to the guy that told them to run > those commands.
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). > 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. > > The current warning message in jc/pull-training-wheel is quite neutral > > between the two options. Perhaps we should lean more towards merging? > > I don't like that message. I would like this for the deprecation period: > > "The pull was not fast-forward, in the future you would have to choose > a merge or a rebase, merging automatically for now. Read 'man git > pull' for more help." > > Then when obsolete: > > The pull was not fast-forward, please either merge or rebase. 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. > "Any more babysitting with essay long messages is counter-productive > to the vast majority of Git users." I think that is what we have advice.* for. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html