Re: --no-edit not respected after conflict

>
> 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".