From: Elijah Newren Date: Wed, 23 Sep 2026 17:49:53 GMT Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: On Wed, Sep 23, 2026 at 10:33 AM Junio C Hamano wrote: > > 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? Yeah, reverting and retrying after the release probably makes sense given how close we are to 2.56.