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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Oct 5, 2009, 10:28 UTC
Message-ID: <4AC9CA4D.7020909@web.de>
In-Reply-To: <7vtyyek4nz.fsf@alter.siamese.dyndns.org>

Junio C Hamano schrieb:

Show 21 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>> 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'".

Right, no reason to use git submodule add here. But in this example submodule1 & submodule2 aren't real submodules, because the .gitmodules file is not created. Or am i missing something?

> If that is the case, I think it is a very sane argument.  It also makes me
> wonder why we need "git submodule add" as a separate step to begin with
> (i.e. "git add" Porcelain could do that behind the scene), but that is
> probably a separate topic.

I think we need git submodule add because it is doing much more than a plain git add. It also does the clone and creates the .gitmodules file needed later.

My everyday use case looks different. When i start a new project where i want to use two of libraries living in their own git repo, i do:

   $ git init toplevel
   $ cd toplevel
   $ git submodule add git://mygitserver/submodule1.git submodule1
   $ git submodule add git://mygitserver/submodule2.git submodule2
   $ git commit -m 'Initial setup with submodule1 & submodule2'

After the submodule add submodule1, submodule2 and .gitmodules are added to the index and the two repositories are cloned, so i just have to do a commit when ready.

And with my patch the two submodule add lines read:

   $ git submodule add git://mygitserver/submodule1.git
   $ git submodule add git://mygitserver/submodule2.git

Which then resembles the command i would use when i want to clone them on their own:

   $ git clone git://mygitserver/submodule1.git

Show 11 quoted lines

>> 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.
> 
> In real life, it is very likely $overthere does _not_ end with submodule1,
> and your suggestion would probably be more useful than the patch under
> discussion, I think.

Actually, for me $overthere is _always_ a treeish path (e.g. ends with submodule1 or submodule1.git). And almost always i have no reason to name the local directory different than the repo.

Jens