Re: Git Notes idea.

> On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:
> 
> > > 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.

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

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