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

Reply via email to