Re: Storing refs in the odb

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