On Wed, Dec 17, 2008 at 4:11 AM, Jeff King <peff@xxxxxxxx> 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. > This is my concern with keeping a history of the notes pseudo-branch. Let us say that I do the following 1) on branch A commit a 2) add note a` 3) on branch B commit b 4) add note b` 5) on branch B commit c 6) add note c` 7) delete branch A 8) gc after a time such that a is pruned Now either I will always have anote a` -- 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
