Re: Commit notes workflow

From: ydirson@free.fr <ydirson@free.fr>
Date: Jun 15, 2011, 09:20 UTC
Message-ID: <243233943.1008861308129613120.JavaMail.root@zimbra44-e7.priv.proxad.net>
In-Reply-To: <201106141215.50689.johan@herland.net>

Show 16 quoted lines

> > 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.