On Wednesday 15. June 2011, ydirson@xxxxxxx wrote: > > > 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. The reason we put the limitation there, is to prevent the notes code from screwing with non-notes trees. The notes code reorganizes the notes tree depending on the number of tree entries, in order to achieve acceptable performance for notes trees of all sizes. Therefore, you definitely DON'T want the notes code rummaging around in non-notes trees (especially if some of your tree entries can be mistaken for strings of hex digits). That said, the example you give above ("refs/remote-notes/foo" -> "refs/notes/refs/remote-notes/foo" is obviously a stupid failure, and should be fixed. Considering "refs/*" to be absolute seems safe to me. (Obviously we loose the "refs/notes/refs/*" namespace, but I can live with that.) ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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