[RFC] git-submodule: multiple-level modules definition

["Ping Yin" <pkufranky@gmail.com>]

1. .gitmodules supports multiple submodule level definition

This follows suggestions from Linus and and Sven Verdoolaege etc.
See "Let .git/config specify the url for submodules"
(http://article.gmane.org/gmane.comp.version-control.git/48939).

.gitmodules with with multiple level of indirection
------------------------------------------------------
[submodule "service"]
    submodule = crawler
    submodule = search
[submodule "crawler"]
    submodule = util
    submodule = imcrawter
[submodule "search"]
    submodule = util
    submodule = imsearch
[submodule "util"]                      (1)
    url = git://xyzzy/util.git
[submodule "imsearch"]
    path = search/imsearch
    url = git://xyzzy/imsearch.git
[submodule "imcrawler"]
    path = crawler/imcrawter
    url = git://xyzzy/imcrawter.git

(1): path default to submodule name
------------------------------------------------------

To simplify the case, submodule sections with submodule attribute should
have neither path attribute nor url attribute (if have, should be ignored).

2. Designate modules by logical names instead of real path

"--name|-n" options is proposed with which modules are designated by logical
names instead of real paths as following example shows.

Identical commands forms with/without "--name"
---------------------------------------------------
$ git submodule XXX util imcrawler              (1)
$ git submodule XXX -n crawler                  (2)
$ git submodule XXX util imcrawler imsearch     (3)
$ git submodule XXX -n service                  (4)
$ git submodule XXX -n crawler search           (5)

* XXX represent list, update or init, but not add
* (1) and (2) are idetical conditionally (explained below)
* (3), (4) and (5) are idetical conditionally
---------------------------------------------------

There are still minor difference between these two forms.

In the no "--name" form, the path parameter may be not the real submodule
path, and it just acts as the filter for real submodule paths.

In the "--name" form, name parameter must be the logical name, and the real
paths corresponding to the logical name may be neither a submodule path nor
even existent. How to handle such a path depends on the subcommand.

  1) status: Output 0{40} as the sha1. Doing this can remind the user to
     add the path as submodule or delete the path from .gitmodules.
  2) update: Skip that path and issue a warning
  3) init: Also init for that path

So in the example above, commands (1) and (2) are identical only when util and
imcrawler are already submodules.

3. Add submodules in batch with "git submodule add --name"

The former workflow to add submodules is adding one by one with
"git submodule add url path" which then modifies .gitmodules. However,
sometimes it may be more convenient to work in the reverse way: edit
.gitmodules first and then add submodules in batch.

Now "git submodule add --name modulename" can help us to do that. It will
find all submodules corresponding to the logical name and add them in batch
by using the path and url from .gitmodules. Of course, it will skip those
paths which have already been submodules.

4. Do we really need 'init' subcommand?

I think .gitmodules should have been bound more tightly with "git submodule".
Now it seems that 'update' or 'status' can still be performed without
.gitmodules after "git submodule init".

So why not to read submodules info from .gitmodules directly just like what
.gitignore nor .gitattributes have been dealt with? Just for editing them
more free?

>From another point, correspoingding to .gitignore we have .git/info/exclude
which just records some paths special to the local repository. But
.git/info/exclude can't replace .gitignore. But why can .git/config replace
.gitmodules which is a naive attribute of the repository?

After introducing multi-level module definition, .gitmodules becomes
more naive to the repository. And it becomes more inappropriate to put
all .gitmodules contents into .git/config since multi-level module
definition shouldn't be edited outside .gitmodules.


-- 
Ping Yin