On Sat, 2 Dec 2006, Josef Weidendorfer wrote: > > > > The only _true_ namespace would be the SHA1 of the commit (and maybe allow > > a pointer to a tag too, but the namespace ends up being the same). > > I am not so sure about this. > Perhaps we want the namespace to be more than the space of commit ids. I don't think it would be wrong at all to have a "link object" type, and have the "link" tree entry actually point to that "link object" instead of pointing directly to the commit in the submodule. And yes, that extra indirection would allow for more flexibility (the "link object" can contain comments about the particular version used, pointers to where you can get it - whether human-readable or strictly meant for automation - etc etc). So I agree with Andy Parkins' comment about the link object allowing not only extended namespaces, but also allowing a certain amount of flexibility (ie there's some built-in extensibility and ability to perhaps add future fields if there's a new object type). I just want the naming of the links themselves to use all the same SHA1 hashes etc, so that you always have a very explicit, and very trustworthy version - and never end up in the situation that you know which repository you want at that position, but you don't know exactly which commit in that repo was supposed to be checked out with that particular version of the super-module. Linus - 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