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

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

[Patrick Steinhardt]

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 <ps@pks.im>
---
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

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

[Phillip Wood]

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

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

[Phillip Wood]

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

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

[Junio C Hamano]

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?

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

[Elijah Newren]

On Wed, Sep 23, 2026 at 10:33 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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?

Yeah, reverting and retrying after the release probably makes sense
given how close we are to 2.56.

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

[Johannes Sixt]

[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

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

[Jiang Xin]

On Thu, Sep 24, 2026 at 2:10 PM Johannes Sixt <j6t@kdbg.org> 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
>

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

[Elijah Newren]

Hi Patrick,

On Wed, Sep 23, 2026 at 6:16 AM Patrick Steinhardt <ps@pks.im> 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 <ps@pks.im>
> ---
> 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?

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

[Junio C Hamano]

Elijah Newren <newren@gmail.com> 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.

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

[Patrick Steinhardt]

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 <ps@pks.im> 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

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

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> 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?

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

[Patrick Steinhardt]

On Wed, Sep 23, 2026 at 11:33:20AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> 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

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

[Elijah Newren]

On Wed, Sep 23, 2026 at 11:33 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Patrick Steinhardt <ps@pks.im> 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.