On Dec 8, 2007 12:00 AM, Ping Yin <pkufranky@xxxxxxxxx> wrote: > I have a super project with many submodules. Each kind of role may > check out different set of submodules. There are some common modules > which are almost checked out by every role. > > Here comes my question: how to implement this elegantly? If all > submodules are put in the same .gitmodules, every role has to in the > command line manually designate all submodules to be checked out. > However, it's hard to remember which submodules is required by which > role, not to mention the so huge .gitmodules. Maybe a script for each > role can help, but it's a little ugly. > > If the name for '.gitmodules' is configurable, we can check in > modules.roleA and modules.roleB, etc. Then role A can designate the > corresponding modules.roleA as .gitmodules. Furtherly, if mutiple > names are allowed, for common modules, we can have modules.common and > then submodule.defaultnames="modules.common, modules.roleA" to avoid > duplicated module name entires in both modules.roleA and > modules.roleB. > > I have gone deeply into git-submodule.sh and see > "GIT_CONFIG=.gitmodules" is used. However, configuable multiple names > can't be implemented in this way. > > Recap: > 1. configurable name for '.gitmodules' > 2. better to allow mutiple names > 3. the implementation issue for mutiple names > Can anyone give me some suggestion? Does it make sense to make GIT_CONFIG record multiple config files, such as "GIT_CONFIG=modules.roleA:modules.roleB"? Or any better way? > -- > Ping Yin > -- 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
