# [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again 13 messages from 2026-09-23 to 2026-09-27. Participants: Patrick Steinhardt, Phillip Wood, Junio C Hamano, Elijah Newren, Johannes Sixt, Jiang Xin. Thread: https://gitlist.dev/t/66376 ## Patrick Steinhardt, 2026-09-23 13:16 Subject: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: <20260923-pks-rebase-conflict-bug-v1-1-3d3ccf5022bc@pks.im> ``` In 6257588252 (commit: refuse to amend during conflict resolution, 2026-09-01), we have introduced logic to git-commit(1) that makes it refuse creating a commit in some cases. This was done to remove a set of common foot guns. One of these foot guns is when the user is performing an interactive rebase that stops at a conflict. Most of the time when we stop at a specific commit we want the user to amend the HEAD commit, so they have been trained to use `git commit --amend`. But when there's a conflict, they are instead supposed to commit it directly without amending the HEAD commit. So to remove that common pit fall, git-commit(1) now refuses amending in that situation. The logic that detects this scenario checks whether the file "rebase-merge/stopped-sha" exists, while "rebase-merge/amend" doesn't. And this is exactly the case when git-rebase(1) has stopped at such a conflicting commit. But there's one problem here: this state persists even after the user has already committed the resolved conflict, and consequently they still cannot amend after they have done so. This is overly restrictive though, as it's quite likely that a user may want to change the resolved commit once again. Ideally, we'd be able to easily check whether HEAD has already been updated to have the resolved conflict. But it seems like we do not have sufficient information to determine the original state of HEAD when the interactive rebase has stopped, so this is not a workable solution. 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. But the whole way that we track rebase state is somewhat iffy in the first place. Signed-off-by: Patrick Steinhardt --- Hi, this is a regression caused by 6257588252 (commit: refuse to amend during conflict resolution, 2026-09-01). Ideally, we should probably fix it before we release Git 2.56. I'm not particularly happy with the proposed fix -- it feels quite fishy to use the existence of MERGE_MSG as a proxy for whether or not the user has already committed the resolved conflict. I couldn't come up with a better proxy though, so if you have one please let me know. Thanks! Patrick --- sequencer.c | 4 ++++ t/t3404-rebase-interactive.sh | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+) diff --git a/sequencer.c b/sequencer.c index e25ef5eb61..0f718c1d38 100644 --- a/sequencer.c +++ b/sequencer.c @@ -7045,9 +7045,13 @@ enum ongoing_operation sequencer_ongoing_operation(struct repository *r, * `amend` unless it stopped with HEAD already pointing at the commit * to be amended (a clean edit/reword stop); its absence therefore * marks a conflicted stop. + * + * Note that we also check for MERGE_MSG. This is to catch the case + * where the user has already resolved and committed the conflict. */ if (file_exists(apply_dir()) || (file_exists(rebase_path_stopped_sha()) && + file_exists(git_path_merge_msg(r)) && !file_exists(rebase_path_amend()))) return ONGOING_REBASE_CONFLICT; diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index 8c63682b7f..d55afaa113 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh @@ -2486,6 +2486,40 @@ test_expect_success 'non-merge commands reject merge commits' ' test_cmp expect actual ' +test_expect_success 'can amend after committing a conflict' ' + test_when_finished rm -rf repo && + git init repo && + ( + cd repo && + + test_commit original file && + test_commit modified file && + cat >todo <<-EOF && + break + edit $(git rev-parse HEAD) + EOF + set_replace_editor todo && + git rebase -i HEAD~ && + + # Modify "file" to cause a conflict. + echo conflict >file && + git commit -a --message conflict && + test_must_fail git rebase --continue 2>err && + test_grep "Resolve all conflicts manually" err && + + # Resolve the conflict. + echo resolved >file && + git add file && + git commit --message resolve && + + # And now try to amend to the conflict. This operation should + # succeed. + echo change >file && + git commit --amend -a --no-edit && + git rebase --continue + ) +' + # This must be the last test in this file test_expect_success '$EDITOR and friends are unchanged' ' test_editor_unchanged --- base-commit: 3bc0341126508f78f5869cbfc0005e987efdf0c7 change-id: 20260923-pks-rebase-conflict-bug-176e325ad079 ``` ## Phillip Wood, 2026-09-23 14:02 Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: <20260923-pks-rebase-conflict-bug-v1-1-3d3ccf5022bc@pks.im> ``` Hi Patrick On 23/09/2026 14:16, Patrick Steinhardt wrote: > In 6257588252 (commit: refuse to amend during conflict resolution, > 2026-09-01), we have introduced logic to git-commit(1) that makes it > refuse creating a commit in some cases. This was done to remove a set of > common foot guns. > > One of these foot guns is when the user is performing an interactive > rebase that stops at a conflict. Most of the time when we stop at a > specific commit we want the user to amend the HEAD commit, so they have > been trained to use `git commit --amend`. But when there's a conflict, > they are instead supposed to commit it directly without amending the > HEAD commit. So to remove that common pit fall, git-commit(1) now > refuses amending in that situation. > > The logic that detects this scenario checks whether the file > "rebase-merge/stopped-sha" exists, while "rebase-merge/amend" doesn't. > And this is exactly the case when git-rebase(1) has stopped at such a > conflicting commit. > > But there's one problem here: this state persists even after the user > has already committed the resolved conflict, and consequently they still > cannot amend after they have done so. This is overly restrictive though, > as it's quite likely that a user may want to change the resolved commit > once again. > > Ideally, we'd be able to easily check whether HEAD has already been > updated to have the resolved conflict. But it seems like we do not have > sufficient information to determine the original state of HEAD when the > interactive rebase has stopped, so this is not a workable solution. Yes, that's unfortunate - I think there is an argument that rebase should be writing ".git/rebase-merge/stopped-head" when it stops. That would make it easy to detect if the user has committed since the rebase stopped. At the moment "git rebase --continue" will happily commit any staged changes with the message from the commit that was being picked when the rebase stopped, even if the user has already committed a conflict resolution. Fixing that is definitely not -rc2 material. In general we should be discouraging users from committing conflict resolutions themselves as it is a hang-over from the way "git merge" originally worked that is error prone and loses the original authorship when applied to "git rebase" > 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, but I'm not convinced by the test > diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh > index 8c63682b7f..d55afaa113 100755 > --- a/t/t3404-rebase-interactive.sh > +++ b/t/t3404-rebase-interactive.sh > @@ -2486,6 +2486,40 @@ test_expect_success 'non-merge commands reject merge commits' ' > test_cmp expect actual > ' > > +test_expect_success 'can amend after committing a conflict' ' > + test_when_finished rm -rf repo && > + git init repo && This test file is one of the slowest already, surely we don't need a whole new repository and commit setup - can't we just add git commit -F .git/MERGE_MSG && git commit --amend -m amended to the end of 'commit --amend is refused at a rebase conflict stop' which was added by 6257588252. That would also check that committing a conflict resolution works as well. Thanks Phillip > + ( > + cd repo && > + > + test_commit original file && > + test_commit modified file && > + cat >todo <<-EOF && > + break > + edit $(git rev-parse HEAD) > + EOF > + set_replace_editor todo && > + git rebase -i HEAD~ && > + > + # Modify "file" to cause a conflict. > + echo conflict >file && > + git commit -a --message conflict && > + test_must_fail git rebase --continue 2>err && > + test_grep "Resolve all conflicts manually" err && > + > + # Resolve the conflict. > + echo resolved >file && > + git add file && > + git commit --message resolve && > + > + # And now try to amend to the conflict. This operation should > + # succeed. > + echo change >file && > + git commit --amend -a --no-edit && > + git rebase --continue > + ) > +' > + > # This must be the last test in this file > test_expect_success '$EDITOR and friends are unchanged' ' > test_editor_unchanged > > --- > base-commit: 3bc0341126508f78f5869cbfc0005e987efdf0c7 > change-id: 20260923-pks-rebase-conflict-bug-176e325ad079 ``` ## Phillip Wood, 2026-09-23 14:22 Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: <24cc4bcc-1d26-46f5-a502-ba673713f4f0@gmail.com> In-Reply-To: ``` 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 Phillip ``` ## Junio C Hamano, 2026-09-23 17:33 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? ``` ## Elijah Newren, 2026-09-23 17:48 Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: <20260923-pks-rebase-conflict-bug-v1-1-3d3ccf5022bc@pks.im> ``` Hi Patrick, On Wed, Sep 23, 2026 at 6:16 AM Patrick Steinhardt wrote: > > In 6257588252 (commit: refuse to amend during conflict resolution, > 2026-09-01), we have introduced logic to git-commit(1) that makes it > refuse creating a commit in some cases. This was done to remove a set of > common foot guns. > > One of these foot guns is when the user is performing an interactive > rebase that stops at a conflict. Most of the time when we stop at a > specific commit we want the user to amend the HEAD commit, so they have > been trained to use `git commit --amend`. But when there's a conflict, > they are instead supposed to commit it directly without amending the > HEAD commit. So to remove that common pit fall, git-commit(1) now > refuses amending in that situation. Are they supposed to commit it directly? The conflict advice tells them to stage the resolution and run "git rebase --continue". In fact, there appear to be a number of problems with using a plain "git commit"; more on that below. > The logic that detects this scenario checks whether the file > "rebase-merge/stopped-sha" exists, while "rebase-merge/amend" doesn't. > And this is exactly the case when git-rebase(1) has stopped at such a > conflicting commit. > > But there's one problem here: this state persists even after the user > has already committed the resolved conflict, and consequently they still After reading ahead, should this be "...has already committed the resolved conflict via a plain 'git commit'"? Resolving it via "git rebase --continue" doesn't have this problem. > cannot amend after they have done so. This is overly restrictive though, > as it's quite likely that a user may want to change the resolved commit > once again. Oof. Thanks for finding and reporting this. > Ideally, we'd be able to easily check whether HEAD has already been > updated to have the resolved conflict. But it seems like we do not have > sufficient information to determine the original state of HEAD when the > interactive rebase has stopped, so this is not a workable solution. > > 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. But the whole way > that we track rebase state is somewhat iffy in the first place. > > Signed-off-by: Patrick Steinhardt > --- > Hi, > > this is a regression caused by 6257588252 (commit: refuse to amend > during conflict resolution, 2026-09-01). Ideally, we should probably fix > it before we release Git 2.56. > > I'm not particularly happy with the proposed fix -- it feels quite fishy > to use the existence of MERGE_MSG as a proxy for whether or not the user > has already committed the resolved conflict. I couldn't come up with a > better proxy though, so if you have one please let me know. Yeah, I'm also a bit worried about using MERGE_MSG here. In particular, git reset removes MERGE_MSG without moving HEAD. With this patch, a subsequent git commit --amend -a is therefore allowed while the conflict resolution is still uncommitted, bringing back the foot-gun that 6257588252 was trying to prevent. For the short-term 2.56, we could either revert that series (it's a long-standing bug after all) and try again after the release. Alternatively, we could record HEAD when the sequencer stops, perhaps in rebase-merge/stopped-head, and then reject the amend while HEAD still equals stopped-head and allow it once a plain commit has advanced HEAD. stopped-sha would remain until rebase --continue, since it is needed for the rewritten-commit mapping and fixup/squash bookkeeping. Longer term, I wonder whether plain "git commit" should be rejected while resolving conflicts for rebase, am, cherry-pick, and revert, with users directed to the corresponding "--continue" command. Plain commit has a surprising collection of behaviors: * During am or an apply-backend rebase, it ignores final-commit and author-script, losing the original message, author, and author date. The corresponding --continue will report "No changes - did you forget to use 'git add'?" even though the user already added and committed the resolution. Amid the generic recovery advice, the user must infer that the corresponding "--skip" is now needed to bypass the patch that their manual commit already handled. * During a merge-backend rebase, it reads MERGE_MSG, so the message survives, but the original author and author date do not. * It may bypass sequencer options such as explicit signing and date-handling options. * --abort behavior then varies by operation: rebase returns to the original commit (orig-head), `am` leaves you at the manual commit, and cherry-pick and revert refuse to rewind because HEAD moved. Having the operation own both the commit and its state transition seems much easier to reason about. I would leave "git merge" as an exception, given the very long-standing "resolve, add, commit" workflow, but I think plain "git commit" should eventually be disallowed as a way to resolve conflicts for other commands. That's post-2.56 work. For now I think either reverting (and trying again after the release), or recording HEAD in stopped-head seems preferable to relying on MERGE_MSG. Thoughts? ``` ## Elijah Newren, 2026-09-23 17:49 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. ``` ## Junio C Hamano, 2026-09-23 17:59 Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: ``` Elijah Newren writes: > Longer term, I wonder whether plain "git commit" should be rejected > while resolving conflicts for rebase, am, cherry-pick, and revert, > with users directed to the corresponding "--continue" command. Plain > commit has a surprising collection of behaviors: > ... > workflow, but I think plain "git commit" should eventually be > disallowed as a way to resolve conflicts for other commands. > > That's post-2.56 work. I would say castrating "git commit" so that it can only do a plain vanilla committing, while it may be a very good move from everything you said above, is post-3.0, not post-2.56, work ;-). > For now I think either reverting (and trying > again after the release), or recording HEAD in stopped-head seems > preferable to relying on MERGE_MSG. Between the two I'd say giving us a chance for a clean start is far more preferrable than repeating "Patrick thought of MERGE_MSG and after a few hours Phillip and Elijah thought of a more robust new mechanism. Let's hope there is no more holes found in the newly proposed mechanism in another few hours" after -rc2 got tagged. ``` ## Patrick Steinhardt, 2026-09-23 18:23 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:48:14AM -0700, Elijah Newren wrote: > Hi Patrick, > > On Wed, Sep 23, 2026 at 6:16 AM Patrick Steinhardt wrote: > > > > In 6257588252 (commit: refuse to amend during conflict resolution, > > 2026-09-01), we have introduced logic to git-commit(1) that makes it > > refuse creating a commit in some cases. This was done to remove a set of > > common foot guns. > > > > One of these foot guns is when the user is performing an interactive > > rebase that stops at a conflict. Most of the time when we stop at a > > specific commit we want the user to amend the HEAD commit, so they have > > been trained to use `git commit --amend`. But when there's a conflict, > > they are instead supposed to commit it directly without amending the > > HEAD commit. So to remove that common pit fall, git-commit(1) now > > refuses amending in that situation. > > Are they supposed to commit it directly? The conflict advice tells > them to stage the resolution and run "git rebase --continue". In > fact, there appear to be a number of problems with using a plain "git > commit"; more on that below. I dunno. All I can say is that I've always been committing directly myself. So it's certainly a workflow that used to work alright. And... > > The logic that detects this scenario checks whether the file > > "rebase-merge/stopped-sha" exists, while "rebase-merge/amend" doesn't. > > And this is exactly the case when git-rebase(1) has stopped at such a > > conflicting commit. > > > > But there's one problem here: this state persists even after the user > > has already committed the resolved conflict, and consequently they still > > After reading ahead, should this be "...has already committed the > resolved conflict via a plain 'git commit'"? Resolving it via "git > rebase --continue" doesn't have this problem. ... honestly I don't think I even had it in my mind that you can just continue the rebase and that does everything for you. Thing is, I also like to verify the result of the merge, and committing myself allows me to do that immediately. [snip] > > I'm not particularly happy with the proposed fix -- it feels quite fishy > > to use the existence of MERGE_MSG as a proxy for whether or not the user > > has already committed the resolved conflict. I couldn't come up with a > > better proxy though, so if you have one please let me know. > > Yeah, I'm also a bit worried about using MERGE_MSG here. In particular, > > git reset > > removes MERGE_MSG without moving HEAD. With this patch, a subsequent > > git commit --amend -a > > is therefore allowed while the conflict resolution is still > uncommitted, bringing back the foot-gun that 6257588252 was trying to > prevent. > > For the short-term 2.56, we could either revert that series (it's a > long-standing bug after all) and try again after the release. > Alternatively, we could record HEAD when the sequencer stops, perhaps > in rebase-merge/stopped-head, and then reject the amend while HEAD > still equals stopped-head and allow it once a plain commit has > advanced HEAD. stopped-sha would remain until rebase --continue, > since it is needed for the rewritten-commit mapping and fixup/squash > bookkeeping. > > Longer term, I wonder whether plain "git commit" should be rejected > while resolving conflicts for rebase, am, cherry-pick, and revert, > with users directed to the corresponding "--continue" command. Plain > commit has a surprising collection of behaviors: > > * During am or an apply-backend rebase, it ignores final-commit and > author-script, losing the original message, author, and author date. > The corresponding --continue will report "No changes - did you forget > to use 'git add'?" even though the user already added and committed > the resolution. Amid the generic recovery advice, the user must infer > that the corresponding "--skip" is now needed to bypass the patch that > their manual commit already handled. True, that's an issue I've been hitting a bunch of times. > * During a merge-backend rebase, it reads MERGE_MSG, so the message > survives, but the original author and author date do not. > > * It may bypass sequencer options such as explicit signing and > date-handling options. > > * --abort behavior then varies by operation: rebase returns to the > original commit (orig-head), `am` leaves you at the manual commit, and > cherry-pick and revert refuse to rewind because HEAD moved. > > Having the operation own both the commit and its state transition > seems much easier to reason about. I would leave "git merge" as an > exception, given the very long-standing "resolve, add, commit" > workflow, but I think plain "git commit" should eventually be > disallowed as a way to resolve conflicts for other commands. It certainly is much easier to reason about, true. But it's definitely a breaking change for something that mostly works alright and that does have some benefits over the "sanctioned" way of doing this via git-rebase(1). > That's post-2.56 work. For now I think either reverting (and trying > again after the release), or recording HEAD in stopped-head seems > preferable to relying on MERGE_MSG. > > Thoughts? I think reverting is probably the safest change for now, and we can then discuss how to properly handle this. I'm not a fan myself of refusing the commit outright as that would break my own workflow. And I'd assume that I'm probably not the only person using that workflow, also because it does let you inspect the result before you move on. It makes me wonder whether we can instead fix git-commit(1) itself to maybe not reset authorship information. But that's probably a much harder change to do, and probably it would make the mess that we have with the ".git/rebase-merge" state directory even bigger. Thanks! Patrick ``` ## Junio C Hamano, 2026-09-23 18:33 Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: ``` Patrick Steinhardt writes: > I think reverting is probably the safest change for now, and we can then > discuss how to properly handle this. I'm not a fan myself of refusing > the commit outright as that would break my own workflow. And I'd assume > that I'm probably not the only person using that workflow, also because > it does let you inspect the result before you move on. Yup, splitting a commit into multiple pieces and other manipulation is easier to do if we are allowed to "git commit" in the middle of a "rebase -i" session, and if "git commit" is to be allowed, "git commit --amend" needs to be allowed immediately following that "git commit", if only to reword a misspelt log message. > It makes me wonder whether we can instead fix git-commit(1) itself to > maybe not reset authorship information. But that's probably a much > harder change to do, and probably it would make the mess that we have > with the ".git/rebase-merge" state directory even bigger. I do not think I understand what you mean by "fix git-commit". Make it pay attention to some file in .git/ directory and override the authorship information over what it usually uses, and make sure it removes that file after it consumed it, or something like that? ``` ## Patrick Steinhardt, 2026-09-23 18:38 Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: ``` On Wed, Sep 23, 2026 at 11:33:20AM -0700, Junio C Hamano wrote: > Patrick Steinhardt writes: > > It makes me wonder whether we can instead fix git-commit(1) itself to > > maybe not reset authorship information. But that's probably a much > > harder change to do, and probably it would make the mess that we have > > with the ".git/rebase-merge" state directory even bigger. > > I do not think I understand what you mean by "fix git-commit". Make > it pay attention to some file in .git/ directory and override the > authorship information over what it usually uses, and make sure it > removes that file after it consumed it, or something like that? Yeah, exactly. The fact that it resets authorship information of a conflicting commit is probably quite surprising overall as an outcome. It's arguable whether this even qualifies as "fix", as in the end git-commit(1) simply does what it always does. But it probably doesn't match the expected outcome in many cases. Patrick ``` ## Elijah Newren, 2026-09-23 19:11 Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: ``` On Wed, Sep 23, 2026 at 11:33 AM Junio C Hamano wrote: > > Patrick Steinhardt writes: > > > I think reverting is probably the safest change for now, and we can then > > discuss how to properly handle this. I'm not a fan myself of refusing > > the commit outright as that would break my own workflow. And I'd assume > > that I'm probably not the only person using that workflow, also because > > it does let you inspect the result before you move on. > > Yup, splitting a commit into multiple pieces and other manipulation > is easier to do if we are allowed to "git commit" in the middle of a > "rebase -i" session, and if "git commit" is to be allowed, "git > commit --amend" needs to be allowed immediately following that "git > commit", if only to reword a misspelt log message. Makes sense. > > It makes me wonder whether we can instead fix git-commit(1) itself to > > maybe not reset authorship information. But that's probably a much > > harder change to do, and probably it would make the mess that we have > > with the ".git/rebase-merge" state directory even bigger. > > I do not think I understand what you mean by "fix git-commit". Make > it pay attention to some file in .git/ directory and override the > authorship information over what it usually uses, and make sure it > removes that file after it consumed it, or something like that? Yes, `git commit` already does something analogous with CHERRY_PICK_HEAD: it uses the referenced commit as the source of author information via read_commit_message("CHERRY_PICK_HEAD"), reads the proposed log message from MERGE_MSG, and consumes CHERRY_PICK_HEAD after a successful commit in sequencer_post_commit_cleanup(). Teaching git commit to consume REBASE_HEAD in the same way seems promising. "git am" is harder; it doesn't have a specific pseudoref so we'd have to dig it out of the author-script and final-commit state files. ``` ## Johannes Sixt, 2026-09-24 06:10 Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: <6ff9d1ac-ff06-439c-bb0a-ce57742e8ff9@kdbg.org> In-Reply-To: ``` [Cc: Jiang Xin] Am 23.09.26 um 19:49 schrieb Elijah Newren: > Yeah, reverting and retrying after the release probably makes sense > given how close we are to 2.56. The reverted series (0f8e75abebff) re-introduced one translatable string ("You are in the middle of a rebase -- cannot amend."), which tranlators may have removed from *.po files by now. -- Hannes ``` ## Jiang Xin, 2026-09-27 08:04 Subject: Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again Message-ID: In-Reply-To: <6ff9d1ac-ff06-439c-bb0a-ce57742e8ff9@kdbg.org> ``` On Thu, Sep 24, 2026 at 2:10 PM Johannes Sixt wrote: > > [Cc: Jiang Xin] > > Am 23.09.26 um 19:49 schrieb Elijah Newren: > > Yeah, reverting and retrying after the release probably makes sense > > given how close we are to 2.56. > > The reverted series (0f8e75abebff) re-introduced one translatable string > ("You are in the middle of a rebase -- cannot amend."), which tranlators > may have removed from *.po files by now. Thanks for the heads-up. I noticed the revert commit upstream. I will rebase all l10n commits onto the new upstream branch to prevent the reverted commits from being reintroduced, and will try to restore the reverted l10n entries. > > -- Hannes > ```