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

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