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

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