Re: [PATCH 6/6] RFC - Notes merge: die when asked to merge a non-existent ref.

From: Jeff King <peff@peff.net>
Date: Jun 20, 2011, 07:16 UTC
Message-ID: <20110620071607.GB15246@sigill.intra.peff.net>
In-Reply-To: <201106200003.46490.johan@herland.net>

On Mon, Jun 20, 2011 at 12:03:46AM +0200, Johan Herland wrote:

Show 17 quoted lines

> > +	if (!peel_to_type(o.remote_ref, 0, NULL, OBJ_COMMIT))
> > +		die("'%s' does not point to a commit", o.remote_ref);
> 
> Hmm. I'm not sure requiring the remote ref to always point to a _commit_ is 
> the right solution here. In previous discussions on the notes topic, some 
> people (Peff?) expressed a need/interest for history-less notes refs (i.e. a 
> notes tree where we don't keep track of its development, but only refer to 
> the latest/current version). Obviously, there are two ways to implement 
> history-less notes refs: (a) making the notes ref point to a notes commit 
> without any parents (i.e. each notes commit is a root commit), or (b) making 
> the notes ref point directly at the notes _tree_ object (i.e. no commit 
> object at all).
> 
> I can't remember off the top of my head whether our earlier discussions on 
> this topic resulted in us excluding support for option (b), but if we 
> didn't, it should be possible to merge notes refs where one or both refs 
> point directly at a tree object, and your above line would break this.

The notes-cache.[ch] implementation uses history-less notes for textconv caching. Since it's just a cache, we don't care about history or merging. And keeping a history would just mean useless old versions of the cache are kept longer than necessary.

I ended up using a commit with no parents to store the cache. I don't recall offhand whether there were any complications with using a raw tree, but I realized that I needed some place to put extra metadata like the cache validity. Wrapping the tree object in a commit provided that place.

I don't think there is any real reason for somebody to need a bare tree of notes. There is a certain elegance that refs can point directly to trees in git, but the overhead of a single commit object to wrap it is just not a big deal[1].

I didn't test, but I doubt that "git merge" will handle bare trees; this would provide analagous behavior for notes-merging. But maybe I'm wrong.

-Peff

[1] The only other time I recall seeing a bare tree is linux-2.6's v2.6.11 tag. And even there it is wrapped by a tag object, so that Linus could include metadata (a comment and a GPG signature). There's really no reason that couldn't have had a commit, except that doing it as a tree shows off how cool git is. :)