Re: Commit notes workflow

[Johan Herland <johan@herland.net>]

On Wednesday 15. June 2011, ydirson@free.fr 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@herland.net>
www.herland.net