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

From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>,
	"John Keeping" <john@keeping.me.uk>
Cc: "Felipe Contreras" <felipe.contreras@gmail.com>,
	<git@vger.kernel.org>, "Andreas Krey" <a.krey@gmx.de>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Wed, 4 Sep 2013 23:08:46 +0100	[thread overview]
Message-ID: <7DC052455C7C4B50A4EAFC1EF63D006C@PhilipOakley> (raw)
In-Reply-To: xmqqa9jso69u.fsf@gitster.dls.corp.google.com

From: "Junio C Hamano" <gitster@pobox.com>
> John Keeping <john@keeping.me.uk> writes:
>
>> I think there are two distinct uses for pull, which boil down to:
>>
>>     (1) git pull
>>     (2) git pull $remote $branch
>>
>> For (1) a merge is almost always the wrong thing to do since it will 
>> be
>> backwards and break --first-parent.
>>
>> But for (2) a merge is almost always the correct thing to do (in fact 
>> it
>> may even be correct to create a merge commit even when this fast
>> forwards) because this most likely comes for a pull request workflow.
>
> Peff already covered (1)---it is highly doubtful that a merge is
> "almost always wrong".  In fact, if that _were_ the case, we should
> simply be defaulting to rebase, not failing the command and asking
> between merge and rebase like jc/pull-training-wheel topic did.
>
> We simply do not know what the user wants, as it heavily depends on
> the project, so we ask the user to choose one (and stick to it).

We only offer a limited list. It won't be sufficient for all use cases. 
It wasn't for me.

The ability to say 'stop' if it doen't match expectations, as 
the --no-ff option would give, would be a help, as the user can then 
decide what to do (read the manual or `google` the problem perhaps ;-). 
the option of having a hook (if suggested), while suitable for advanced 
users won't help those that need that help, rather a few simple safe 
options are needed.

I generally support the ability to set an option to reject non-ff pulls.

>
> I am not sure about (2), either.  Is it really "almost always the
> correct thing to do"?  I tend to think myself that (2) is a lot more
> likely to prefer merging than (1) would, but I certainly wouldn't
> say "almost always".  Again if "almost always" were the case,
> wouldn't it make sense for that mode of invocation of the command to
> even defeat "pull.rebase" configuration and default to merge, unless
> explicitly told to "pull --rebase" from the command line?
>
> (the last question is rhetoric, if anybody is wondering).
> --
Philip 