Junio C Hamano wrote:
> 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
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.
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