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

>      git config get --all --regexp --show-names --show-scope notes | column -t
>      global  format.notes      true
>      global  notes.rewriteref  refs/notes/commits
>      local   core.notesref     refs/notes/benknoble/commits
>      local   notes.rewriteref  refs/notes/benknoble/commits
>      local   notes.displayref  refs/notes/origin/amlog
> 
> So I would have expected the notes to get rewritten?
> 
> - Running "git commit … --amend …" (author change and all) rewrites the notes
> - Running "git rebase -x echo" rewrites the notes (well, it has
> nothing to do right now, so it doesn't modify anything; however, I'm
> 99.9% convinced that when I did a plain rebase earlier today the notes
> were preserved, just like they are all the time)
> 
> It's just the combination that loses them :/
> 

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

> Thanks
> 
> Phillip
> 
> [1] https://github.com/phillipwood/git/commits/wip/rebase-update-rewritten
> 
>>      git config get --all --regexp --show-names --show-scope notes | 
>> column -t
>>      global  format.notes      true
>>      global  notes.rewriteref  refs/notes/commits
>>      local   core.notesref     refs/notes/benknoble/commits
>>      local   notes.rewriteref  refs/notes/benknoble/commits
>>      local   notes.displayref  refs/notes/origin/amlog
>>
>> So I would have expected the notes to get rewritten?
>>
>> - Running "git commit … --amend …" (author change and all) rewrites 
>> the notes
>> - Running "git rebase -x echo" rewrites the notes (well, it has
>> nothing to do right now, so it doesn't modify anything; however, I'm
>> 99.9% convinced that when I did a plain rebase earlier today the notes
>> were preserved, just like they are all the time)
>>
>> It's just the combination that loses them :/
>>
> 

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

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