On Saturday 2006, December 02 11:55, Josef Weidendorfer wrote: > > > 100644 blob 08602f522183dc43787616f37cba9b8af4e3dade xdiff-interface.c > > > 100644 blob 1346908bea31319aabeabdfd955e2ea9aab37456 xdiff-interface.h > > > 040000 tree 959dd5d97e665998eb26c764d3a889ae7903d9c2 xdiff > > > 050000 link 0215ffb08ce99e2bb59eca114a99499a4d06e704 xyzzy > > > > > > where that 050000 is the new magic type (I picked one out of my *ss: > > > it's not a valid type for a file mode, so it's a godo choice, but it > > > could be anythign that cannot conflict with a real file), which just > > > specifies the "link" part. The SHA1 is the SHA1 of the commit, and the > > > "xyzzy" is obviously just the name within the directory of the > > > submodule. > > > > Can I argue that the hash in that object should actually be to a real > > object in the supermodule repository rather than a link? > > That is the thing we already are discussing here :-) > IMHO, submodule IDs make a lot of sense, and this needs to specify the > submodule ID at every link. Which would force us to use seperate objects. I wasn't really going as deep as a submodule ID. Just moving the submodule commit hash from the supermodule tree, to a supermodule "link" object. What goes in that object is a separate problem I believe. The primary reason I think it's a good idea is that it is consistent with every other hash in the tree. It seems to be inconsistent to say blob objects have a hash that points to an object in this repo tree objects have a hash that points to an object in this repo link objects have a hash the points to an object in a different repo > However, I am not speaking about some separation issue, but more about a > design decision. For fetching/pulling/merging, you want be able to > distinguish submodules not only by the commit id into the submodule: > multiple > submodules could link into the same DAG (but different branches) of another > repository which would make unique fetching/pulling/merge decisions > difficult, especially when you think about the possibility that the > relative root path of a submodule in a supermodule should be able to change > at any supermodule commit. I can't say I've understood what you mean here. There is no difference in facilities if there is a link object in the local repository as well. It's merely an extra layer of indirection. Apart from the tiny cost of dereferencing that link object, there is no disadvantage. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@xxxxxxxxx - 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