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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 15, 2013, 18:00 UTC
Message-ID: <CALkWK0n0y6OPJvYjNeEbUx_CC58vHRRLCsmJtws+RKyv3wRTwQ@mail.gmail.com>
In-Reply-To: <7vvc7nu1hu.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 7 quoted lines

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

Right. But I'm still worried about .git/modules/$name. Can you explain why it's a better idea than having a dedicated ~/bare? In the case when I have it in ~/bare, I can do many more interesting things: for instance, if I cloned a repository that is actually another project's submodule for instance, I don't have to re-clone it when I clone that superproject. What's more? I can remove submodules and attach a worktree to my ~/bare/repo.git and use it as a separate repository easily. I can move submodules between projects. In comparison, .git/modules/$name just seems like a mess.

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

Well, I'm against the change in principle because add operates on worktree paths, not URLs. I don't want to change that arbitrarily.