Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 23, 2026, 17:33 UTC
- Message-ID
- <xmqqik3vc1pc.fsf@gitster.g>
- In-Reply-To
- <24cc4bcc-1d26-46f5-a502-ba673713f4f0@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
Show 18 quoted lines
> 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?