On Mon, Jun 20, 2011 at 12:03:46AM +0200, Johan Herland wrote:
> > + 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. :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html