In general I think it is a mistake to overload "git clone" with the notion of adding a submodule. 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. (This may benefit from "git clone" learning some kind of --separate-git-dir option, but that's irrelevant to me.) On 13-04-15 04:19 AM, Ramkumar Ramachandra wrote: > > Why would a user *want* a full clone inside a git worktree? Please try to be careful with your assumptions. I could have ~/.git/ to maintain revisions of various personal files, config .dotfiles, scripts in ~/bin/ and so on. I could also have various projects' repos under ~/Code, where I do my "real" work: ~/Code/git/.git/ ~/Code/DayJob/.git/ ~/Code/project-foo/.git/ Now, are these Code/* repos inside ~/.git/'s worktree or not? I'd really prefer them not to be. I would be especially upset to have some "magic" that automatically adds new clones inside ~/Code/ to ~/.git/. M. -- 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