From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 29 Nov 2021 18:17:11 GMT
Subject: Re: [PATCH v11 2/2] am: support --empty=<option> to handle empty patches
Message-ID: <xmqqo8623jyw.fsf@gitster.g>
In-Reply-To: <CABPp-BF-eYcJ7eS==VK3M2xOqf5z4KNK4dP6qd_UcfLO1NWBeg@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

>> +--empty=(die|drop|keep)::
>> +       By default, or when the option is set to 'die', the command
>> +       errors out on an input e-mail message that lacks a patch. When
>> +       this option is set to 'drop', skip such an e-mail message instead.
>> +       When this option is set to 'keep', create an empty commit,
>> +       recording the contents of the e-mail message as its log.
>
> What does 'errors out' mean?  Is the am operation aborted, and the
> user return to the pre-am state?  Or is the am operation interrupted,
> with the user being asked to choose whether to keep or drop the patch?

I think it is the same as how "git am" without this sees a piece of
e-mail without any patch in it.  It exits with non-zero status, but
keeps the contents of .git/rebase-apply directory intact so that the
user can decide what the next action should be.  "the command stops
with non-zero status and gives control back to the user" might be a
better explanation.

As to the name of the option's value, I think 'die' is a much better
word than 'ask' for this behaviour.  It is not like we retain
control, give "do you want to do X or Y?"  prompt and do either X or
Y ourselves, which is what I expect out of 'ask'.  If we just exit
with non-zero value and give the control back to the user, then we
are not asking.

This is a tangent, but in the current Documentation/git-am.txt, the
phrasing for "--skip" and "--resolved" are a bit inconsistent.

 - The "--skip" operation calls the situation it is designed to handle
   "an aborted patch".

 - The "--resolved" operation calls it "a patch failure".

The "--abort" operation interestingly does not use any word to
explain the situation it is designed to be used in.  It just
assumes that the user knows "git am" session is somehow still in
effect.