Re: --no-edit not respected after conflict

> On Tue, Mar 23, 2021 at 6:27 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Elijah Newren <newren@gmail.com> writes:
>>
>>> === Current behavior ===
>>>                     Non-conflict commits    Right after Conflict
>>> revert             Edit iff isatty(0)      Edit (ignore isatty(0))
>>> cherry-pick        No edit                 See above
>>> Specify --edit     Edit (ignore isatty(0)) See above
>>> Specify --no-edit  (*)                     See above
>>>
>>> (*) Before stopping for conflicts, No edit is the behavior.  After
>>>      stopping for conflicts, the --no-edit flag is not saved so see the
>>>      first two rows.
>>>
>>> === Expected behavior ===
>>>
>>>                     Non-conflict commits    Right after Conflict
>>> revert             Edit iff isatty(0)      Edit (regardless of isatty(0)?)
>>> cherry-pick        No edit                 Edit (regardless of isatty(0)?)
>>> Specify --edit     Edit (ignore isatty(0)) Edit (ignore isatty(0))
>>> Specify --no-edit  No edit                 No edit
>>>
>>> The thing I'm unsure on is the !isatty(0) handling for revert &
>>> cherry-pick right after a conflict when neither --edit nor --no-edit
>>> are specified.
>>
>> I read the intention behind existing "edit if isatty" as "this is an
>> operation the human reader deserves a chance to explain what was
>> done and why by default".  For example, I read the first entry in
>> your table as: Even if there is no conflict, there should be a
>> convincing explanation when you revert.  On the other hand, if you
>> are cherry-picking without any conflict, the intention should be
>> clear enough in the original commit log message, which ought to be
>> written why applying that change is a good idea, so it would make
>> sense not to invoke editor in that case.
>>
>> If an operation deserves a chance to be explained even in a cleanly
>> auto resolved case, it does deserve the chance even more if hand
>> resolution was required---in addition to the original "what and
>> why", the resolution of the conflict is an additional reason why the
>> human should be given a chance to explain.
>>
>> But if it is an automated process, there is no reason to fail the
>> operation merely because the process is run unattended.  So my
>> recommendation for "regardless of isatty" part is "do not force
>> editing".  The same is true for a human user who declines the chance
>> to explain him/herself with an explicit "--no-edit".
> 
> Thanks.
> 
> Renato: potential fix over here:
> https://lore.kernel.org/git/pull.988.git.git.1616742969145.gitgitgadget@gmail.com/T/#u.
> Could you give it a try?