On Mon, Mar 3, 2008 at 1:11 AM, Ping Yin <pkufranky@xxxxxxxxx> wrote: > 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 > --------------------------------------------------- > Maybe i should introduce more about the background. In my company we try to keep all the codes in a unique big environment which consists of many sub projects (more than 30). These subprojects are hierachily organized. There are different roles which need touch different part of these sub projects. For example, crawler deveoper should touch crawler-related projects, and search developer need touch search-related projects. There are also some common modules which are used by most of these roles. There are also many other roles. So for easy use, we need define one logical name for each kind of role and this name should correspond to all the role-related sub projects. Filtering submodules by path is not so useful for us because role-related projects may live in many different directories. >From the management view of company, all the roles should use the same big environment. And we don't want to use different branch for different roles. So all roles will get the same .gitmodules file. They are not much familiar with git and can't afford to type git init path1 ... pathn each time when they want to build their develop environment. It's more friendly to them if they only need to remember a logical name such as crawler or search. And some people have multiple roles. Sometime they want to work on search and sometimes on crawler. So logical name is very convenient to them. As a conclusion, my main point is 1. Multiple level module definition is very useful since it can help us build hierachy of modules 2. Designating modules by logical name which corresponds to a group of role-related modules is usefull since it can help role-based development much. -- 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
