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.
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.
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 said, I'd still understand if it didn't do that and lost my
note. It would be unfortunate, but it would match today's behavior. I'm ok
with copying over my notes when necessary, I just want Git to handle it when
it's obviously correct (e.g. when the patch-id matches).
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.
For reference, I've been using git v1.9.0. The v1.9.1 release notes don't
mention anything notes-related so I assume these issues still exist.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html