> > A (minor) problem with the second possibility is that this naming > > convention could evolve, eg. if we end up with something like was > > proposed in [1] for 1.8.0. Is there any real drawback with the > first > > suggestion ? > > > > [1] http://marc.info/?l=git&m=129661334011986&w=4 > > My gut feeling is to keep some sort of limit notes refs, and if/when we get > around to implementing my proposal in [1] (or some variation thereof), we > will of course extend the limit to put "refs/remotes/$remote/notes/*" (or > whatever is decided) in the same category as "refs/notes/*". > > In the meantime, I'm unsure if it's a good idea to remove the limitation > altogether (allowing notes refs everywhere), since re-introducing a limit at > a later point will then be MUCH harder... I'm still unsure what that limitation brings to us. OTOH, it has at least one funny downside: when someone tries to refer to some forbidden ref using --ref, it gets silently requalified: $ git notes --ref=refs/remote-notes/foo add $ find .git/refs/notes/ -type f .git/refs/notes/refs/remote-notes/foo $ It just seems so wrong... Surely we can mitigate it by considering a ref starting with "refs/" to be absolute, and thus never prepend "refs/notes/" to it, but it rather sounds to me a symptom that we may not want to filter things anyway. -- 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