Hi, On Wed, 17 Dec 2008, Jeff King wrote: > 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. 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. > > 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. > > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
