Re: Storing refs in the odb
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
Re: Storing refs in the odb
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 -- Johan Herland, jo...@herland.net www.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
Re: Storing refs in the odb
Johan Herland jo...@herland.net writes: 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... I was reacting to this part of your earlier message: 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 You cannot disambiguate, with the thought-experiment in your message I am responding to, between these two: ?? tree 987654... v2.6.11-tree ?? tree 987654... sub where the former is a light-weight tag for that tree, while the latter is merely a subhierarchy in refs/sub/hier/archy, but if you disallow v2.6.11-tree, and if you know this kind of tree is only to express the ref hierarchy, then everything is unambiguous (a commit is not a submodule but is a ref that points at a commit, a blob is a ref that points at a blob like refs/tags/junio-gpg-pub, and tag is a ref that points at the tag). So it was workable alternative implementation of refs (I am not saying it is an improvement, with the atomicity and performance implications we already discussed), if we did not have to worry about a light-weight tag that directly point at a tree. -- 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
Re: Storing refs in the odb
On Mon, May 20, 2013 at 8:28 PM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: 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... I was reacting to this part of your earlier message: 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 You cannot disambiguate, with the thought-experiment in your message I am responding to, between these two: ?? tree 987654... v2.6.11-tree ?? tree 987654... sub where the former is a light-weight tag for that tree, while the latter is merely a subhierarchy in refs/sub/hier/archy, but if you disallow v2.6.11-tree, and if you know this kind of tree is only to express the ref hierarchy, then everything is unambiguous (a commit is not a submodule but is a ref that points at a commit, a blob is a ref that points at a blob like refs/tags/junio-gpg-pub, and tag is a ref that points at the tag). So it was workable alternative implementation of refs (I am not saying it is an improvement, with the atomicity and performance implications we already discussed), if we did not have to worry about a light-weight tag that directly point at a tree. True, unless we were to abuse the mode bits to differentiate between regular-subtree and ref-to-tree cases... ...Johan -- Johan Herland, jo...@herland.net www.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