On Sun, Sep 8, 2013 at 12:21 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote: > >> > It's not if you understand the difference between merge-then-commit and >> > commit-then-merge. But for a clueless user who has been told "replace >> > svn commit" with "git commit && git push" and replace "svn update" with >> > "git pull", it is quite similar. >> >> Well, yeah, but if they are so clueless they have to be told what to >> do, they can be told to do 'git pull --merge' instead, no? > > 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. Fortunately there probably are very few of these users. > 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. "Any more babysitting with essay long messages is counter-productive to the vast majority of Git users." > I guess that works against John's case, though, which is clueless people > working on a project that _does_ care about the shape of history. At > least they would have to stop and think for a moment, though, which > might help (and maybe convince them to ask more clueful project > members). I don't know. Or google 'git pull' 'git merge' 'git rebase' or 'git non-fast-forward'. -- Felipe Contreras -- 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