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

Reply via email to