From: Renato Botelho <garga@FreeBSD.org>
To: Elijah Newren <newren@gmail.com>, Junio C Hamano <gitster@pobox.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: --no-edit not respected after conflict
Date: Fri, 26 Mar 2021 12:36:54 -0300 [thread overview]
Message-ID: <8818df56-027a-a113-ab02-b91cf18c710e@FreeBSD.org> (raw)
In-Reply-To: <CABPp-BEmKfZUHjRECWy96Y2BrhqxQPedYC4_WvXaTXShE=B5HA@mail.gmail.com>
On 26/03/21 04:19, Elijah Newren wrote:
> 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?
It worked! Thanks!
--
Renato Botelho
prev parent reply other threads:[~2021-03-26 15:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 14:44 --no-edit not respected after conflict Renato Botelho
2021-03-19 21:30 ` brian m. carlson
2021-03-22 13:03 ` Renato Botelho
2021-03-22 17:14 ` Elijah Newren
2021-03-24 0:59 ` Elijah Newren
2021-03-24 1:27 ` Junio C Hamano
2021-03-26 7:19 ` Elijah Newren
2021-03-26 15:36 ` Renato Botelho [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8818df56-027a-a113-ab02-b91cf18c710e@FreeBSD.org \
--to=garga@freebsd.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).