Junio C Hamano schrieb: > 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'". 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 >> 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 -- 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