"Sverre Hvammen Johansen" <hvammen@xxxxxxxxx> writes:
> On Tue, Mar 11, 2008 at 1:15 AM, Jakub Narebski <jnareb@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
