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

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

On Mon, Mar 3, 2008 at 1:11 AM, Ping Yin <pkufranky@gmail.com> 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