From: Junio C Hamano Date: Wed, 23 Sep 2026 18:33:20 GMT 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?