On Mon, May 20, 2013 at 7:21 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Johan Herland <jo...@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.
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...
Johan Herland, <jo...@herland.net>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html