Junio C Hamano wrote: > 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. Right. But I'm still worried about .git/modules/$name. Can you explain why it's a better idea than having a dedicated ~/bare? In the case when I have it in ~/bare, I can do many more interesting things: for instance, if I cloned a repository that is actually another project's submodule for instance, I don't have to re-clone it when I clone that superproject. What's more? I can remove submodules and attach a worktree to my ~/bare/repo.git and use it as a separate repository easily. I can move submodules between projects. In comparison, .git/modules/$name just seems like a mess. > 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. Well, I'm against the change in principle because add operates on worktree paths, not URLs. I don't want to change that arbitrarily. -- 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