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

From: Elijah Newren <newren@gmail.com>
Date: Sep 23, 2026, 19:11 UTC
Message-ID: <CABPp-BEQSx4m3BcT28CpVGCtsH75+x3gmv4OJz_ecLVLx+kBWg@mail.gmail.com>
In-Reply-To: <xmqqzex7akcv.fsf@gitster.g>

On Wed, Sep 23, 2026 at 11:33 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

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

Show 9 quoted lines

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