On Fri, 18 May 2007, Petr Baudis wrote: > On Fri, May 18, 2007 at 02:00:07PM CEST, Jakub Narebski wrote: >> There is a bit ugly solution for this: instead of using symbolic name >> in versioned .gitmodules for a subproject (for a repo), use subproject >> identifier (inode), and put it in the tag object (or config) together with >> the URL. Git would then search all the subproject / submodule info for >> a given inode. You could have more than one inode / identifier name for >> a subproject repo; this would avoid the "independently created" issue >> with using inodes / file-ids in distributed SCM. One would have to >> ensure however that different subprojects get assigned different inodes. > > Well, then it doesn't make any difference, no? You just renamed the > problem but it stays the same - to ensure uniqueness even across > repositories. > > Ok, you can declare now that you will just think out a UUID for the > subproject, but aside of not fitting well with the whole git philosophy, > then you don't need the indirection again, just use the UUID as the tag > name. > > I have the feeling that I'm missing something basic in your proposal... I was thinking about _automatic_ UUID, generated by git. For example it could be sha1 of first subproject commit which appeared in supermodule. It is easy to check if two UUID correspond to the same repository: check if both objects are present, or perhaps that one is reachable from the other, or that they have common parent. This kind of UUID is not that different from (global) SHA1 of object. So the idea is to have versioned, i.e. in-tree mapping from directory names to repositories via some kind of identifier: Junio idea of using URL of repository, with possibility of overriding it in repo config, the idea of using tag name, and having URL for repo in tag contents, and my idea of tag name of tag containing UUID. To find the URL you would search all the repo-tags for UUID, or for existence of commit with given sha1. But I haven't thought this idea through, so it migh be utter rubbish. The porcelain part of subproject / submodule support is not that easy, to cover for moving subproject "mountpoint", project changing URL, conflict of project names and different naming of the same project etc. -- Jakub Narebski Poland - 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