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

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Apr 15, 2013, 20:32 UTC
Message-ID: <516C63DA.4080209@xiplink.com>
In-Reply-To: <7va9ozsk60.fsf@alter.siamese.dyndns.org>

On 13-04-15 02:50 PM, Junio C Hamano wrote:

Show 17 quoted lines

> Marc Branchaud <marcnarc@xiplink.com> writes:
> 
>>> After that "clone" or "init" creates a repository, you still have to
>>> "add" if you want to make it a submodule to the toplevel.
>>
>> To me it makes more sense to move the .git directory when the user invokes
>> "git submodule add" instead of creating it in an unusual place when the
>> sub-repo is cloned.  After all, git can't *know* that it'll be a submodule
>> until it's submodule-added to the super-repo.
> 
> It does not relieve "git add" (or "git submodulea add") from the
> responsibility of moving .git directory.  It only reduces the need
> to do so.
> 
> When the user says "add" and the repository has .git directory in
> it, "add" (or "submodule add") is still responsible for relocating
> it.

So it looks like the proposed change to git-clone provides no benefit to the submodule-adding machinery, which still needs to know when and how to relocate .git directories.

Ram, assuming Junio's explanations match your intentions, if the whole motivation for this change is "to make 'git add' DTRT wrt submodules, and deprecate 'git submodule add'" then I don't think it's bringing you any closer to that goal.

M.