Re: Git Notes idea.
- From
- Govind Salinas <govind@sophiasuchtig.com>
- Date
- Dec 19, 2008, 17:18 UTC
- Message-ID
- <5d46db230812190918qf22b874n8d8aeea557083df8@mail.gmail.com>
- In-Reply-To
- <20081217101110.GC18265@coredump.intra.peff.net>
On Wed, Dec 17, 2008 at 4:11 AM, Jeff King <peff@peff.net> wrote:
Show 30 quoted lines
> 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`