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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 23, 2026, 18:33 UTC
Message-ID: <xmqqzex7akcv.fsf@gitster.g>
In-Reply-To: <arQZDXxf0139omx5@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 5 quoted lines

> 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?