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

>
> Phillip Wood <phillip.wood123@gmail.com> 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?