Re: Git Notes idea.

Hi,

On Wed, 17 Dec 2008, Jeff King wrote:

On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:

quoted

quoted

I agree, I haven't thought of any fix along these lines other than 
to make gc do the clean up.

I have, and IIRC I briefly mentioned it back then.  Basically, you 
will have to add a "git notes gc" or some such, which basically reads 
in the whole notes, traverses all reachable commits, marking the 
corresponding notes, and then writes out all marked notes (leaving the 
other notes behind).

I was thinking something similar, but I think it is even easier. Make
the rule "if we still have the object, then we still have the note".
That has three benefits:

 - implementation is simple: for each note $n, delete it unless
   has_sha1_file($n).

 - it handles notes on non-commit objects

 - it kills off notes when an object is _pruned_, not when it stops
   being _reachable_. So if I delete a branch with a commit found
   nowhere else, its notes will hang around until it is actually pruned.
   If I pull it from lost+found, I still keep the notes.

Note that all of this garbage collection of notes is really just 
removing them from the most current notes _tree_. If the notes structure 
is actually composed of commits, then old notes that are "deleted" will 
still be available historically.

Right.  So my original proposal to use separate refs for separate purposes 
might make sense again, so you can have private as well as public notes.

quoted

I wonder why you speak as if none of that had been implemented yet.  
From my work, it is obvious that hashtable is better than sorted list 
(except for the fan-out, which obviously wants to be an array), and 
from Peff's it is obvious that we want to keep the hashtables in 
memory.

If he is planning on doing a separate pyrite implementation, then it 
_hasn't_ been implemented yet. And I don't care there if he uses hash 
tables or sorted lists or whatever. I think the most important thing is 
getting down the design of the _data structure_, so that we can have a 
compatible implementation inside git itself.

Well, I don't care about pyrite.  As far as I am concerned, it might as 
well use an incompatible version.  I really don't care.

quoted

quoted

IMO notes are just a generallized tag.

IMO notes have nothing to do with a tag.  Tags point to commits (or 
other objects, but that's beside the point here).  Notes are pointed 
_to_ by commits.

I think maybe we are just talking about semantics, but I think notes are
not pointed to by commits. There is an external mapping of commits to
notes, which is very different. I can give you the commit without you
knowing the notes, or that the notes even exist.

But in practice, I don't know if this distinction is going to influence 
any of the design or use.

You are correct, of course, that the commit does not point to the notes 
explicitely, by having a SHA-1 _in_ the commit object.  But the main point 
still stands: you go from commit to note, not from note to commit.  And 
this is in stark contrast to tags, where you go from tag to commit, _not_ 
from commit to tag.

That is a fundamental _difference_ between tags and notes, so that I 
refuse to accept the notion of notes being a generalized form of tags.

Ciao,
Dscho