Thread (8 messages) flat view 8 messages, 3 authors, 2016-06-15

Re: Git Notes idea.

From: Govind Salinas <hidden>
Date: 2016-06-15 22:45:48

On Wed, Dec 17, 2008 at 4:11 AM, Jeff King [off-list ref] wrote:
On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:
quoted
quoted
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`
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help