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

From: Felipe Contreras <felipe.contreras@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Jeff King <peff@peff.net>, 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 17:38:50 -0500	[thread overview]
Message-ID: <CAMP44s0SLoD7ptgiYOg_vq+Jpo5uhWvzFC8Bd76JHo5zbjf8fg@mail.gmail.com> (raw)
In-Reply-To: <20130908172605.GF5359@vauxhall.crustytoothpaste.net>

On Sun, Sep 8, 2013 at 12:26 PM, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
>> On Sat, Sep 7, 2013 at 11:18 PM, Jeff King <peff@peff.net> wrote:

>> >   $ hack hack hack
>> >   $ svn commit ;# oops, somebody else committed in the meantime
>> >   $ svn update
>> >   $ svn commit
>> >
>> > Those people would now have to learn enough to choose between merge and
>> > rebase when running the "git pull".
>>
>> But that's only if they don't care about the shape of history. In my
>> experience the people that cling more to centralized VCS do not like
>> merges, so they rebase everything to make it a straight line. That is
>> much more "svn-like".
>>
>> So chances are they are already doing 'git pull --rebase' (or
>> similar), so their workflow wouldn't be affected.
>
> We end up squashing each project branch into one commit (usually using
> git reset --soft), so we don't care about the shape of history.  Over
> the course of a project branch, in fact, there may be many merges from
> the main release branches (including other projects), so history is
> going to be very messy otherwise.

Yeah, but the key question at hand in this discussion is; what happens
when 'git pull' stops working for them, and they don't know what to
do, will they choose 'git pull --rebase' by mistake?

I say the answer is no, because:

1) As you say in your scenario, somebody is telling these guys what to
do, so when 'git pull' fails, somebody will figure out that they were
doing a merge, so 'git pull --merge' is what they want to type from
now on.

2) Git itself would be warning them for months that a 'non
fast-forward was found, and a merge will be done for them', so when
the warning turns to an error, they'll know they want a merge, so
they'll do 'git pull --merge', either because the warning told them
that's git was doing all along, or because they figured that out by
googling, or reading the man page, or whatever.

Either way, it would not be a big deal for these people, their
user-experience wouldn't be totally broken by this proposed change,
and that is the important conclusion.

-- 
Felipe Contreras