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

[Junio C Hamano <gitster@pobox.com>]

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?