Re: Storing refs in the odb

2013-05-20 Thread Junio C Hamano
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

2013-05-20 Thread Johan Herland
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

2013-05-20 Thread Junio C Hamano
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

2013-05-20 Thread Johan Herland
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