Johan Herland <johan@xxxxxxxxxxx> 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.
--
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