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

From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jeff King <peff@peff.net>
Cc: John Keeping <john@keeping.me.uk>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Andreas Krey <a.krey@gmx.de>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Sun, 8 Sep 2013 01:17:42 -0500	[thread overview]
Message-ID: <CAMP44s3U2rJsqTj4cAOpY1ntum53bEy2cP5XRNaMu5vwnYVoww@mail.gmail.com> (raw)
In-Reply-To: <20130908052107.GA15610@sigill.intra.peff.net>

On Sun, Sep 8, 2013 at 12:21 AM, Jeff King <peff@peff.net> 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