Re: [RFC/PATCH] Fast forward strategies allow, never, and only

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 12, 2008, 04:50 UTC
Message-ID: <7v1w6g8s1w.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <402c10cd0803112124i2726c32m75b9353d902df320@mail.gmail.com>

"Sverre Hvammen Johansen" <hvammen@gmail.com> writes:

Show 10 quoted lines

> On Tue, Mar 11, 2008 at 1:15 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>  > +never::
>>  > +     Generate a merge commit even if the merge resolved
>>  > +     as a fast-forward.
>>
>>  This is equivalent of current '--no-ff'; nevertheless I think that it
>>  would be better to name this strategy 'commit' or 'merge', as in
>>  --ff=merge, or --ff=commit.
>
> If there is consensus to change this I will.

I do not think Jakub's suggestion makes much sense. If --ff stands for "fast forward", then --ff=merge could be explained (very unnaturally) as "(in a) fast forward (situation, create a) merge", which might make some sense as an incomplete sentence, but I cannot explain "commit" like that even with a broken sentence.

Using "fast forward" as a verb ("instead of creating a needless merge, just move the head"), then the mode of operations your patch proposes can be described much clearer. "Never fast forward, always create an artificial merge if needed", "Only fast forward is allowed, never advance this head by creating a true merge", etc.

So I think the wording is fine. What's more necessary in the documention is how and why these restrictions are useful in what situations, workflows and management policies.