Re: BUG? git rebase -x "git commit --amend …" lose s notes

On Wed, Aug 5, 2026 at 12:30 PM Phillip Wood <[email protected]> wrote:
>
> On 05/08/2026 14:42, Phillip Wood wrote:
> > On 05/08/2026 14:13, D. Ben Knoble wrote:
> >> Sigh… I haven't minimized a reproduction case here yet, but maybe
> >> someone can tell me how I'm holding it wrong.
> >>
> >> I have a local branch with notes in refs/notes/benknoble/commits (in
> >> particular, the tip commit has a note). I forgot to adjust my author
> >> email before creating some of these commits, and I wanted to adjust it
> >> to match the mailmap patch I just sent out, so I ran
> >>
> >>      git rebase -x "git commit --no-verify --no-edit --amend
> >> --author='$(git config get user.name) <$(git config get user.email)>'"
> >>
> >> Upon checking (much) later, I discovered the note was missing! It had
> >> not been rewritten. And yet:
> >
> > I suspect the note was rewritten to the un-amended commit (i.e. the
> > commit created by rebase before it ran the exec command). The way the
> > note writing works is that as rebase picks commits it remembers the new
> > object id of each commit and after all the commits have been rebased
> > passes a list of "old-oid new-oid" pairs to "git notes copy". If a
> > commit gets amended by an exec command then we don't record the new
> > object id correctly.

Ah, thanks. That explains what went wrong.

> > I have some old, half finished, patches that try to
> > fix that by making "git commit --amend" update the file where rebase
> > stores the list of rewritten commits. I think it worked for exec
> > commands that run "git commit amend", but the effort got bogged down
> > trying to improve the way we handle commits that are edited. I've just
> > pushed them to [1] if anyone is interested (though the commit messages
> > are dreadful so I don't know how much help the patches will be).
>
> Another approach would be to copy the notes before we stop for an "exec"
> or "edit" command (the latter is complicated by the fact it might have
> conflicts) so that "git commit --amend" could just copy them to the
> amended commit. If we did that we'd want to copy the notes in-process
> rather than forking "git notes copy" before each "exec" command.

Yeah. I wonder if we could give enough information to "exec" commands
so they know what the old OID is, to let them decide what to do with
it? That is, could we expose the old–new list rebase keeps around as a
readable artifact?

The other option that occurs to me is to have an easy way to feed
old–new to "git notes copy" (or any other command) *post* rebase. I
can get at the mapping using git-range-diff, but I still have to
copy-paste or parse the output in a way that feels likely to be
brittle, I think.

> > [1] https://github.com/phillipwood/git/commits/wip/rebase-update-rewritten

I probably won't be taking a look anytime soon, but thanks!

-- 
D. Ben Knoble