Re: Storing refs in the odb

> Johan Herland <johan@herland.net> writes:
>
>>> 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
>> entry pointing to a commit is usually interpreted as a submodule, but
>> that is not what we'd want for the ref tree, and a tree entry pointing
>> at a tag has AFAIK not yet been done), or whether it means we need to
>> come up with a different kind of structure.
>
> You can disallow that only by giving up on being able to express
> Linus's kernel repository, which has an oddball v2.6.11-tree tag.
>
> I do not think that that particular tag in the particular repository
> is too big a show-stopper; if it is only Linus, we can ask him to
> drop that tag (he has v2.6.11 tag object that points at the tree, so
> the users do not lose anything) and be done with it.
>
> But if there are other repositories that tag trees in a similar way,
> that would be a real regression.  We cannot just go ask people to
> change their workflow that depended on using refs that directly
> point at trees overnight.