Re: [RFC 2/2] pull: default pull.ff to "only" when pull.rebase is not set either

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 4, 2020, 02:06 UTC
Message-ID: <xmqqpn3qfhps.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqqmtyuhemi.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 20 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>>> That would require changing the semantics of --ff-only, so that "git
>>> pull --no-rebase --ff-only" doesn't make sense (as --ff-only is
>>> overridden by --no-rebase).
>>
>> I do not think such a conclusion follows from "we do not want to use
>> the 'by default force the --ff-only' when the user chooses between
>> merge and rebase".  Specifically, I do not agree with "as --ff-only
>> is overridden" in your statement.
>
> Ah, sorry, I mis-read your three lines above.
> ...
> And if we introduce a third-way, i.e. "we do not handle the case
> where you have your own development at all, this is only to maintain
> pristine copy from your upstream", and repurpose "--ff-only" for
> that purpose, yes, what you said above does make sense.  At that
> point, there is no reason to disagree with "as --ff-only is
> overridden" part of your statement---in your new world, "--ff-only"
> is redesigned to act that way.

Just to avoid misunderstanding, I only meant to say that the first three lines I quoted is internally consistent (unlike the message I was responding to, in which I said "I disagree---the conclusion does not follow"). It no way means I think such a re-definition of what "--ff-only" means is a great design.

What we want to see can be done without such backward incompatible changes, e.g. declaring the combination of "--ff-only" and "--[no-]rebase" incompatible and/or the last one wins, I would say, and I suspect Alex's RFC was an attempt to make the first step in that direction.

What is most missing in the current system is a fix for the way in which "--rebase" interacts with "--ff-only". Immediately after fetching, if our current branch is not a subset of what we fetched from the other side, the command should die. Otherwise, it should just rebase what we have (which is nothing) on top of the tip of the history of the other side (which is to fast-forward our tip and the working tree to their tip).

Another thing we would want to change is to make the "you must choose between rebase and merge" trigger a lot more lazily. If our side does not have our own development and their history is a descendent of what we have, the user shouldn't have to choose. Only when the history they have does not fast-forward, we have to abort giving the "you must choose between the two" warning message.

When the user tells us to do rebase or merge, nothing (except that "--ff-only" should prevent the rebase from going forward) should have to be changed.