From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: git@vger.kernel.org
Subject: bug: interactive rebase's 'edit' insn copies notes to newly inserted commit
Date: Fri, 23 Aug 2019 15:38:50 +0200 [thread overview]
Message-ID: <20190823133850.GK20404@szeder.dev> (raw)
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 :)
next reply other threads:[~2019-08-23 13:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-23 13:38 SZEDER Gábor [this message]
2019-08-23 16:41 ` bug: interactive rebase's 'edit' insn copies notes to newly inserted commit Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190823133850.GK20404@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).