Junio C Hamano <gits...@pobox.com> writes:

> If the envisioned use of this is to use it as a building block of
> something else that is user-facing (e.g. the user says "git add",
> and before the command finishes, somewhere we internally run "git
> clone"), then would it be possible that you are better off running
> that clone with --separate-git-dir and let it make the gitfile for
> you?

As you may have already guessed, in principle I am all for teaching
"git add" not just to add a submodule itself (which we already do)
but also to record information about the submodule, without having
to delegate it to "git submodule".  "git submodule add" was meant as
an interim measure until we figure out what kind of metainformation
is necessary, and doing things in "git add" has always been a longer
term goal.

There are two ways to "add" a submodule to a superproject.  You may
bring an existing project with "git clone" inside the working tree
of a superproject (which I am guessing is the use case that inspired
this patch), but it will leave the git dir of the submodule embedded
in its working tree.  

You could continue "git clone" and then teach "git add" (or "git
submodule add") to relocate the embedded git directory from the
submodule working tree, you could "git clone" with separate-git-dir
from the beginning, or you could extend "git add", perhaps

    git add --url=git://up.stre.am/repository [--name=name] sub/mod/ule

and do that "git clone --separate-git-dir" internally (which will
mean that the end user will not run "git clone").

Another way ti "add" a submodule is to run "git init" to originate a
new project inside the working tree of a superproject. The resulting
submodule working tree will have the embedded git dir, and again
"git add" (or "git submodule add") could notice and relocate it, but
if the extended "git add" wants to help that use case as well, I
think it is the matter of running "git init --separate-git-dir",
just like "add by cloning from elsewhere" can do the same with the
flag to "git clone".

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