On 13-04-15 01:50 PM, Junio C Hamano wrote:
> Marc Branchaud <mbranch...@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
> 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. Sure, the user might have set
clone.submoduleGitDir somewhere, but users make mistakes, and this setting
makes it harder to clean up a mistake:
git clone foo.git
# Doh! I mean to clone foof.git!
rm -rf foo
# Gah, now there's cruft in my clone.submoduleGitDir...
All that said, the basic idea of being able to configure where "git clone"
stores .git directories might be reasonable. Something like
clone.gitDirHome. It seems like something only a git hacker would ever care
about, but that's no reason not to have such a config option. OTOH, I still
don't see a reason for it, because I don't buy the submodule-at-clone-time
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