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

[Junio C Hamano <gitster@pobox.com>]

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?