Re: Storing refs in the odb

Johan Herland [off-list ref] writes:

quoted

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.