Re: [PATCH RESEND] git submodule add: make the <path> parameter optional
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 5, 2009, 01:31 UTC
- Message-ID
- <7vtyyek4nz.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <alpine.DEB.1.00.0910042304060.4985@pacific.mpi-cbg.de>
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 submodule2and 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'".
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.
> 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.