Marc Branchaud <mbranchaud@xxxxxxxxxxx> writes: > In general I think it is a mistake to overload "git clone" with the notion of > adding a submodule. I agree with that principle, but my understanding is that this effort is not about teaching "git clone" to create a submodule. Both "git clone" and "git init" already know how to use a directory that is outside the working tree of the newly created repository to store its $GIT_DIR and point at it with .git in the working tree using the gitfile mechanism (their --separate-git-dir option). My understanding is that this "config" is about making that option easier to use when you _know_ any new repository you create with "git clone" or "git init" inside your (toplevel super)project's working tree will become its submodule, as it is more convenient to have their $GIT_DIR inside the .git/modules/$name of the superproject. After that "clone" or "init" creates a repository, you still have to "add" if you want to make it a submodule to the toplevel. > If I want to *add* something to a repository, I'll use > some kind of "add" command. To me "git clone" is not the kind of verb I > would expect to add something to some distant-parent .git directory. > > Instead of mucking around with"git clone" I would much rather see "git add" > autodetect URLs and do the submodule thing: > > git add ssh://host/blammo.git > > would clone blammo.git into ./blammo/ and set it up as a submodule inside > $PWD's git repo. I do not think the addition Ram is envisioning in the patch will prevent you from teaching "add" to do that. An implemention of such an addition indeed would most likely use the same --separate-git-dir mechanism anyway. -- 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