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. -- 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
