On Mon, May 20, 2013 at 8:28 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Johan Herland <jo...@herland.net> writes:
>> I wasn't considering disallowing _anything_, rather open up to the
>> idea that a tree object might refer to tag objects as well as
>> commits/trees/blobs. E.g. in my suggested-but-pretty-much-retracted
>> scheme, I was considering whether the tree entry at the "virtual" path
>> "refs/tags/v1.0" should look like this:
>> 100644 blob 123456... v1.0
>> where the blob at 123456... contains the object id of the v1.0 tag
>> object, or whether we should allow the crazyness that is:
>> ?????? tag 987654... v1.0
>> Just a thought experiment...
> I was reacting to this part of your earlier message:
>>>> Of course in either case we couldn't use a tree object directly, because
>>>> these new "reference tree" objects would refer not only to blobs and
>>>> other trees but also to commits and tags.
>>> Indeed. I don't know if the best solution would be to actually _allow_
>>> that (which would complicate the object parsing code somewhat; a tree
> You cannot disambiguate, with the thought-experiment in your message
> I am responding to, between these two:
> ?????? tree 987654... v2.6.11-tree
> ?????? tree 987654... sub
> where the former is a light-weight tag for that tree, while the
> latter is merely a subhierarchy in refs/sub/hier/archy, but if you
> disallow v2.6.11-tree, and if you know this kind of tree is only to
> express the ref hierarchy, then everything is unambiguous (a commit
> is not a submodule but is a ref that points at a commit, a blob is a
> ref that points at a blob like refs/tags/junio-gpg-pub, and tag is a
> ref that points at the tag).
> So it was "workable" alternative implementation of refs (I am not
> saying it is an "improvement", with the atomicity and performance
> implications we already discussed), if we did not have to worry
> about a light-weight tag that directly point at a tree.
True, unless we were to abuse the mode bits to differentiate between
regular-subtree and ref-to-tree cases...
Johan Herland, <jo...@herland.net>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html