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

On Sun, Sep 8, 2013 at 12:21 AM, Jeff King [off-list ref] wrote:

On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:

quoted

quoted

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