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

On Monday 20 June 2011, Jeff King wrote:

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

quoted

quoted

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

You're not wrong. "git merge" when trying to merge a tree object:

  $ git merge ee314a3
  error: ee314a3: expected commit type, but the object dereferences to tree type
  fatal: 'ee314a3' does not point to a commit

So I guess there's no reason to allow notes trees with no commit object.

Yann: Please disregard my complaint on the above two lines.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net