Ramkumar Ramachandra wrote: > When set, > instead of cloning the given repository as-is, it relocates the gitdir > of the repository to the path specified by this variable. Interesting. As the discussion downthread from this illustrated, I am not convinced this is better than a subcommand of "git submodule" for that particular purpose, yet. Is the goal to be able to, under some certain configuration, make "git clone" + "git add" behave like "git submodule add"? [...] > I don't like the > .git/modules nonsense). As Jeff mentioned, a given repository can be a subproject of multiple different containing projects, that use different versions of it. It doesn't make sense for different directories on the filesystem to share an index anyway. Do you want the subprojects to be symlinks to the One True Version of each project? (I can see that working ok in some workflows.) Or do you want subprojects to be lightweight workdirs like git-new-workdir creates, with .git/objects pointing to the project's One True Object Store? That is the part of this design that seems least well fleshed out to me at the moment. I quite like .git/modules/<subproject name> (for some reasons that I've mentioned in other threads) and don't consider it nonsense, which makes me assume I don't understand the goal of this patch, either. Please don't take that personally. Hope that helps, Jonathan -- 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