Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 23, 2026, 17:59 UTC
Message-ID: <xmqq7bkbc0h5.fsf@gitster.g>
In-Reply-To: <CABPp-BFadjqtOB_9cYkrs9UBgTp0hQxu4oiV_yqzYOuiu6g45w@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 9 quoted lines

> Longer term, I wonder whether plain "git commit" should be rejected
> while resolving conflicts for rebase, am, cherry-pick, and revert,
> with users directed to the corresponding "--continue" command.  Plain
> commit has a surprising collection of behaviors:
> ...
> workflow, but I think plain "git commit" should eventually be
> disallowed as a way to resolve conflicts for other commands.
>
> That's post-2.56 work.

I would say castrating "git commit" so that it can only do a plain vanilla committing, while it may be a very good move from everything you said above, is post-3.0, not post-2.56, work ;-).

> For now I think either reverting (and trying
> again after the release), or recording HEAD in stopped-head seems
> preferable to relying on MERGE_MSG.

Between the two I'd say giving us a chance for a clean start is far more preferrable than repeating "Patrick thought of MERGE_MSG and after a few hours Phillip and Elijah thought of a more robust new mechanism. Let's hope there is no more holes found in the newly proposed mechanism in another few hours" after -rc2 got tagged.