On Wed, Apr 17, 2013 at 9:13 PM, Ramkumar Ramachandra <artagnon@xxxxxxxxx> wrote: > Duy Nguyen wrote: >> No, submodule code does not change "git clone". If I'm not mistaken, >> submodule will not kick in until you type "git submodule something". >> If I turn clone.submoduleGitDir on, how can I undo my mistake in a >> user friendly way? > > So, if you currently want to add a submodule, you have to 'git > submodule add', which runs clone internally apart from other things. > How do you undo this mistake? Well, it has "submodule" in the command line. My first reaction would be looking for "git submodule rm" or something. > What I'm essentially proposing is to give the job of cloning back to > clone, and the job of adding back to add, instead of creating an > unnatural abstraction over them using 'git submodule add'. The point > being: why would you ever _want_ to clone inside a worktree unless you > intend to add a submodule? In other words, you intent for running a > 'git clone' inside a worktree is exactly the same as your intent for > running a 'git submodule add' inside a worktree. Ofcourse, if you > have a fringe case where that was _not_ your intent, we'll provide a > command-line switch to turn off the relocation for that clone. No, the point is people make mistakes. What do we do in that case? Or will you introduce yet another "gc" command for clean up ~/bare? -- Duy -- 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