Re: Storing refs in the odb

From: Junio C Hamano <gitster@pobox.com>
Date: May 20, 2013, 18:28 UTC
Message-ID: <7va9npv730.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALKQrgdWx5mw3NCd4JOr3x9M34c2rNjm_tz_C7fm7g7g-LUJZQ@mail.gmail.com>

Johan Herland <johan@herland.net> writes:

Show 14 quoted lines

> 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:

Show 6 quoted lines

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