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

From: Philip Oakley <philipoakley@iee.org>
Date: Sep 4, 2013, 22:08 UTC
Message-ID: <7DC052455C7C4B50A4EAFC1EF63D006C@PhilipOakley>
In-Reply-To: <xmqqa9jso69u.fsf@gitster.dls.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>

Show 23 quoted lines

> 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.

Show 11 quoted lines

>
> 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