Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

[Junio C Hamano <gitster@pobox.com>]

Marc Branchaud <mbranchaud@xiplink.com> writes:

> In general I think it is a mistake to overload "git clone" with the notion of
> adding a submodule.

I agree with that principle, but my understanding is that this
effort is not about teaching "git clone" to create a submodule.

Both "git clone" and "git init" already know how to use a directory
that is outside the working tree of the newly created repository to
store its $GIT_DIR and point at it with .git in the working tree
using the gitfile mechanism (their --separate-git-dir option).  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.

After that "clone" or "init" creates a repository, you still have to
"add" if you want to make it a submodule to the toplevel.

> 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.

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.