Jeff King <peff@xxxxxxxx> writes: > I think this change affects not just "git notes merge", but all of the > notes lookups (including just "git notes show"). However, I'd argue > that's a good thing, as it allows more flexibility in note storage. The > downside is that if you have a notes ref like > "refs/notes/refs/heads/master", you can no longer refer to it as > "refs/heads/master" (you have to use the fully qualified name to get the > note). But: > > 1. This makes the notes resolution a lot more like regular ref > resolution (i.e., we now allow fully qualified refs, and you can > store remote notes outside of refs/notes if you want to). > > 2. There are already a bunch of names that have the same problem. You > cannot refer to "refs/notes/notes/foo" as "notes/foo", nor > "refs/notes/refs/notes/foo" as "refs/notes/foo". Yes, these are > silly names, so is the example above. > > So it's backwards incompatible with the current behavior, but I think in > a good way. Yup, I agree with the analysis. >> --- >> notes.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > I think you need to adjust t3308 (and you should probably add a new test > exercising your case; this is exactly the sort of thing that it's easy > to accidentally regress later). > > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html