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