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 -- 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
