From: Renato Botelho Date: Fri, 26 Mar 2021 15:36:54 GMT Subject: Re: --no-edit not respected after conflict Message-ID: <8818df56-027a-a113-ab02-b91cf18c710e@FreeBSD.org> In-Reply-To: On 26/03/21 04:19, Elijah Newren wrote: > On Tue, Mar 23, 2021 at 6:27 PM Junio C Hamano wrote: >> >> Elijah Newren 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? It worked! Thanks! -- Renato Botelho