bug: interactive rebase's 'edit' insn copies notes to newly inserted commit

I noticed that somehow two commits on the same branch ended up with the same note attached. I believe that this is the result of me using interactive rebase's 'edit' instruction to insert new commits, and then it copied the note from the edited commit to the commit from from where I 'git rebase --continue'-ed.

Here's a simple illustration:

  $ git log --oneline --notes
  70be36f (HEAD -> master) third
  02b5ef9 second
  Notes:
      A note on the second commit
  
  f93427a first
  $ git config --get notes.rewriteref 
  refs/notes/commits
  $ git rebase -i HEAD^^
  ## Change the instruction sheet to 'edit' the "second" commit ##
  Stopped at 02b5ef9...  second
  You can amend the commit now, with
  
    git commit --amend 
  
  Once you are satisfied with your changes, run
  
    git rebase --continue

  $ git commit --allow-empty -m "Insert new commit #1"
  [detached HEAD 2d05076] Insert new commit #1
  $ git commit --allow-empty -m "Insert new commit #2"
  [detached HEAD 0ed24dc] Insert new commit #2
  $ git rebase --continue 
  Successfully rebased and updated refs/heads/master.
  $ git log --oneline --notes
  b02a593 (HEAD -> master) third
  0ed24dc Insert new commit #2
  Notes:
      A note on the second commit
  
  2d05076 Insert new commit #1
  02b5ef9 second
  Notes:
      A note on the second commit
  
  f93427a first

Notice how the note now appears twice, because it has been copied from the (unmodified) "second" commit to the last commit that has been inserted on top before continuing.

I certainly didn't expect this, and can't readily see a use case where it's desirable, but maybe I just lack imagination :) However, once rebase stops for the 'edit' instruction the user can do just about anything, so I'm not sure how rebase could figure out when to copy the note and when not.

This is not a regression of following the rewrite in C, the scripted version had the same behavior (I think v1.8.0 was the oldest I tried).

This doesn't happen when inserting a 'break' instruction between picking the "second" and "third" commits, and then adding new commits. Alas, the 'break' instruction is not even a year old, and I have been using 'edit' for this purpose for over a decade now... so re-training my fingers will be hard :)

SZEDER Gábor <szeder.dev@gmail.com> writes:

True.

Meaning the original note for the second one is carried to the rewritten second, and the one for the third is carried to the rewritten third? That would be a reasonable outcome.

Probably a section in the tutorial and/or the example section of the "git rebase -i" documentation should encourage use of "break" when inserting a brand-new commit in the middle.

Thanks.