Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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'".
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html