Re: Git Notes idea.

[Jeff King <peff@peff.net>]

On Fri, Dec 19, 2008 at 11:38:55AM -0600, Govind Salinas wrote:

> 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.

Yes, that's correct.

> Given this problem, is it really such a good idea to keep the history?

I think so. Otherwise how will you push and pull notes? You won't even
know which one is the more recent tree, let alone handle any merges
caused by editing notes in two places.

> On the other, other hand, pushing and pulling notes if a history is kept
> will have to involve a lot of rebasing/merging.

Depending on your workflow. It might just involve a lot of fast forwards
if the note writer is in one place.

> A possible solution is that notes are per-branch,
> 
> refs/notes/heads/master
> refs/notes/heads/foo/bar
> refs/notes/remotes/baz/bang

Sorry, I don't quite get it. You are asking for per-branch notes that
keep history, or per-branch notes that don't keep history?

If the former, then you haven't solved the cruft accumulation problem.
You can get obsolete notes in your note history by rebasing on a branch
that is long-running (which is OK as long as you haven't published
_those particular_ commits). Or are you proposing to rebase and cleanup
the notes history every time you do a destructive operation?

If the latter, then I don't see how you've solved the push-pull and
merge problem (which you need history for).

But in either case, I think the solution is non-intuitive. If I annotate
a commit, and then merge the commit from one branch to another,
shouldn't the annotation stay?


Really, I am not sure this is worth getting too concerned about. Since
we are talking about cruft in the _history_ of the notes branch, it
won't impact actual notes usage (which will always just deal with the
most recent tree). So really we are talking about some uninteresting
objects in the db, which wastes some space. In practice, I suspect this
won't be that large because notes themselves are going to be relatively
short and in many cases, repetitive (i.e., many annotations may have the
same blob hash for several commits). And if it is a space problem, then
the right solution is to periodically truncate the notes history by
rewriting.

-Peff