Kevin Ballard <> writes:

> I’ve started using notes recently, and I have notes.rewriteRef set so that
> when I rebase, my notes will be kept. Unfortunately, it turns out that if a
> rebase deletes my local commit because it already exists in upstream, it
> doesn’t copy the note to the upstream commit. It seems perfectly reasonable to
> me to expect the note to be copied to the upstream commit, as it represents
> the same change.

That would cut both ways, depending on the use case.  I suspect that
those who use notes as remainder of what are still to be sent out
would appreciate the current behaviour.

> One complication I can see is when my local commit is deleted not because it
> exists upstream, but because it ends up being an empty commit due to the
> changes existing across multiple upstream commits. In this case I see no
> alternative but to have the note disappear. But I think that's acceptable.

Oh, no question about that.

> Another potential issues is if the commit exists upstream, but the surrounding
> context has changed enough that it contains a different patch-id. In this
> case, I would want Git to take the extra effort to correlate the upstream
> commit with my local one (it has the same message, modulo any Signed-Off-By
> lines, the same authorship info, and all the - and + lines in the diff are
> identical).

That would be an orthogonal improvement, I would think.  Such a
smarter "patch-id may mistake it, but it is a moral equivalent"
detection would not only be useful for copying notes, but also for
skipping the commit from getting replayed in the first place, no?

> On a semi-related note, I don't see why Git should be warning about
> notes.displayRef evaluating to a reference that doesn't exist. It doesn't
> exist because I haven't created any notes for that ref in this repository yet.
> But that doesn't mean I won't be creating them eventually, and when I do I
> want them to be displayed.

That also cuts both ways. I think a warning is primarily to let
those who mistyped the refname take notice.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to