Thread (20 messages) flat view 20 messages, 4 authors, 2016-06-15

Re: Commit notes workflow

From: Johan Herland <hidden>
Date: 2016-06-15 22:51:28

On Wednesday 15. June 2011, ydirson@free.fr wrote:
quoted
quoted
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
quoted
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, [off-list ref]
www.herland.net
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help