Re: [PATCH] fix "git-submodule add a/b/c/repository"

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Jul 8, 2008, 03:26 UTC
Message-ID: <4872DE54.5010804@gmail.com>
In-Reply-To: <7v7ibxxfje.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 6 quoted lines

> I'd like to hear clarifications on two counts, please?
>  (1) If Sylvain wanted to have that appear at dir0/dir1/init not init,
>      would it have been sufficient to give that path twice (once for
>      <repository> and another for <path> parameter) to make things work as
>      expected?
>

git-submodule really requires two arguments:

    $ git submodule add <URL> <relative-path-to-module-in-tree>

and supports two modes:

1) relative-path exists and is a valid repo: just add the module, it was 
created in tree, the user is expected to eventually push this to the 
given URL so other users will get this as normal. This exists to 
simplify the process of creating a repo to begin with.

2) relative-path doesn't exist: clone from the URL. This is the normal use.
submodule supports adding a module in one of two ways:

So,

    $ git submodule add   dir0/dir1/init   dir0/dir1/init

will add the repo, but also makes the repo its own origin. I don't think this makes sense.

Show 10 quoted lines

>  (2) Is it generally considered a sane use case to specify an existing
>      repository inside the working tree of a superproject as a submodule
>      using "git submodule add" like Sylvain's example did?
>
>      I would have understood if the command were "git add dir0/dir1/init",
>      but I have this vague recolleciton that "git submodule add" is about
>      telling our repository about a submodule that comes from _outside_.
>
>
>

Adding an existing in-tree repo, ala

 $ git submodule add <intended-URL> <path>

is there to ease the initial creation of a submodule. It can be created and registered in-tree, and later pushed to the server. This is sane, but is not the normal usage (makes sense only on creation).

Mark