Re: Git Notes idea.

Sorry, hit the send key accidentally.

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

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

quoted

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.