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.
On Mon, May 20, 2013 at 7:21 PM, Junio C Hamano [off-list ref] wrote:
Johan Herland [off-list ref] writes:
quoted
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.
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
--
Johan Herland, [off-list ref]
www.herland.net