Subject: RE: [RFC PATCH 01/35] merge: improve fatal fast-forward message

From: "Randall S. Becker" <[email-masked]>
Date: Tue, 6 Jul 2021 18:26:14 -0400

On July 6, 2021 5:54 PM Junio C Hamano wrote:
>"Randall S. Becker" <[email-masked]> writes:
>
>> On July 6, 2021 4:56 PM, Junio C Hamano wrote:
>>>"Randall S. Becker" <[email-masked]> writes:
>>>
>>>>>If you do:
>>>>>
>>>>>  % git merge --ff-only
>>>>>  fatal: Not possible to fast-forward, aborting.
>>>>>
>>>>>That "aborting" part is redundant; we know `git merge` should abort
>>>> if the fast-forward is not possible, we explicitely told git to do
>>>> that.
>>>>
>>>> `git merge` is a special operation where errors (conflicts, for one)
>>>> may leave the repository in a merge pending state where you
>>>> subsequently may have to use `git merge --abort` to reset the
>>>> situation or `git add` to continue. The `aborting` output makes it
>>>> clear that you do not have to do the `--abort` and *cannot* do the
>>>> `add` because there was an implicit `--abort` done resulting from
>>>> the failure. This is important information for the user.
>>>
>>>If so, adding ", aborting" to the end is misleading.  In this
>>>particular failure mode, the command pretends that the merge did not even start.
>>
>> You know that, and I know that. I contend that git users do not
>> generally want to care about failure modes. While a flow description
>> might be instructive, I doubt many git users would look at it. We can
>> only hope that front ends know how to make this clean for them.
>
>They may not care about "failure modes" but they would want to know that in this situation, unlike other times, they do not have to say
>"git merge --abort" (or "git reset --hard").  Saying ", aborting"
>does not help as much as saying say ", not starting a merge", for example.

I like that a lot, actually "not starting a merge" is much more helpful.