Sorry, hit the send key accidentally. 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 me restate what you are saying with an example 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 a note a` as an object forever even though the only commit that points to it is gone or I have to re-write the history of the notes branch from the point that it was added. Given this problem, is it really such a good idea to keep the history? Of course the other side of this conversation is that the merge operation will be more complex since the following can also happen 9) push notes 10) user 2 pulls notes but still has commit a and note a` On the other, other hand, pushing and pulling notes if a history is kept will have to involve a lot of rebasing/merging. Just to throw an idea out... A possible solution is that notes are per-branch, refs/notes/heads/master refs/notes/heads/foo/bar refs/notes/remotes/baz/bang and then it is easier to deal with. A published branch's notes are isolated from the changes in unpublished branches. And since published branches aren't *supposed* to change, then the notes should also always be fast forwards. Similarly, if a branch is not considered stable, like pu or even next, then the associated notes branch could be forced in the same way. Rebase, cherry-pick and merge (and possibly branch/checkout) would have to be updated to handle notes, which is the down side. It also doesn't solve the issue of a history causing us to keep notes after the aren't useful anymore. So perhaps we could use the above layout with no history? Thanks, Govind. -- 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
