BUG? git rebase -x "git commit --amend …" loses notes

BUG? git rebase -x "git commit --amend …" loses notes

[D. Ben Knoble]

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

-- 
D. Ben Knoble

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

[Phillip Wood]

Hi Ben

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

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

[Phillip Wood]

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.

Thanks

Phillip

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

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

[D. Ben Knoble]

On Wed, Aug 5, 2026 at 12:30 PM Phillip Wood <phillip.wood123@gmail.com> 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