Re: --no-edit not respected after conflict

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26/03/21 04:19, Elijah Newren wrote:
On Tue, Mar 23, 2021 at 6:27 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:

Elijah Newren <newren@xxxxxxxxx> 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@xxxxxxxxx/T/#u.
Could you give it a try?

It worked! Thanks!

--
Renato Botelho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux