From: Junio C Hamano Date: Wed, 23 Sep 2026 17:33:19 GMT Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: <24cc4bcc-1d26-46f5-a502-ba673713f4f0@gmail.com> Phillip Wood writes: > On 23/09/2026 15:02, Phillip Wood wrote: >> On 23/09/2026 14:16, Patrick Steinhardt wrote: >>> Instead, use the existence of "MERGE_MSG" to figure out whether the user >>> has already resolved and committed the conflict. It feels somewhat fishy >>> to base our decisions on the existence of that particular file, as it >>> really is only a proxy for what we are actually after. >> >> I think that's probably the best we can do. If, after committing a >> conflict resolution from "git rebase", the user runs a merge/cherry- >> pick/revert that has conflicts, then "MERGE_MSG" will also exist, but we >> don't want them to amend that case either so it should be fine. >> >> The code changes look good, > > Let me rephrase that. The code changes look good for "git rebase", but > do we have a similar problem with "cherry-pick", "merge" and "revert"? > > Thanks Now, would it be a -rc2 material to just revert the regressing change out of the release and restart the effort post release?