From: Junio C Hamano Date: Wed, 23 Sep 2026 17:59:50 GMT Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: Elijah Newren writes: > 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.