Re: [PATCH RESEND] git submodule add: make the <path> parameter optional

Hi,

On Sun, 4 Oct 2009, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

So far, I started submodules by cloning them, doing everything in the 
other files needed to integrate, and then actually wondered why "git 
submodule add" could not simply take the (relative) path to the 
checked-out submodule and deduce the URL from the corresponding config?

Let me try to rephrase the above to see if I understand what you are
doing.  When building a top-level superproject that uses two submodules
from other places, you would do:

	$ git init toplevel
        $ cd toplevel
        $ git clone $overthere submodule1
        $ git clone $elsewhere submodule2
        $ edit Makefile common.h
        $ git add Makefile common.h submodule1 submodule2

and by "the corresponding config", you mean "submodule1/.git/config
already records that it came from $overthere, and there is no reason to
say it again in 'git submodule add $overthere submodule1'".

Yes, that's what I meant.

But I do like your idea of enhancing "git add" to do this.  Then we can 
keep "git submodule add" as-is, and then it actually makes sense to make 
the <path> parameter optional: "git submodule add" is then about _cloning_ 
and adding the submodule.  Which is not my scenario.

quoted

So I would actually vote for making the <repository> parameter 
optional...

In your "git submodule add submodule1", it would be quite clear that it is
a local path and <repository> is being omitted.  On the other hand, if you
said "git submodule add $overthere" without submodule1, because $overthere
is not likely to be an in-tree path, it also would be clear that it is
omitting the path.  IOW, these two typesavers are not mutually exclusive.

I thought about that, but it seems a bit too magical, and it is obvious 
that

	git submodule add $(pwd)/bla

would test that magic.

Ciao,
Dscho