Junio C Hamano wrote: > Any new configuration variable brings its own problem by forcing > existing users to countermand it explicitly from the command line. > If the --separate-git-dir would not work for your application, you > need a new feature and you can achieve the same by adding a new > command line option (say, --submodule-git-dir), that would be more > preferrable.
I'm getting a little tired of your first instinct to oppose every new addition to git. (Ofcourse I understand your attitude as the maintainer, but still) It doesn't make sense as a command-line option, because it is "magic" that kicks in only when git clone is executed inside an existing git worktree. The point is that the user doesn't have to remember anything special: a normal git clone already does the right thing outside a git worktree; my proposal is to make it do the right thing inside a git worktree as well. Although I'm not against allowing a user to create a "full clone" inside a git repository by overriding clone.submoduleGitDir via a command-line option, I really cannot see why this would be anything but rare. Why would a user *want* a full clone inside a git worktree? Also, naming it --submodule-git-dir can cause a lot of confusion: --separate-git-dir names a specific directory to put the GITDIR in, while --submodule-git-dir names a directory inside which to create other named directories to put GITDIRs in. Ofcourse clone.submoduleGitDir is a bad name too: any suggestions? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
