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

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

[SZEDER Gábor]

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

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

[Junio C Hamano]

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

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

True.

> This doesn't happen when inserting a 'break' instruction between
> picking the "second" and "third" commits, and then adding new commits.

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.

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

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.