On Sunday 11 November 2007, Junio C Hamano wrote: > "Yin Ping" <pkufranky@xxxxxxxxx> writes: > > > I think it's this kind of case in most open-source project. However, > > in a company environment, superprojects may be not so super. > > Let's not say "most open-source" nor "company", because I think > nobody said anything that substantiates that the commit density > characteristics I described is typical for most open-source, nor > what you said is typical for corporate development projects, in > this thread so far. > > If "superprojects is not so super", why are you using submodule > to bind these, instead of using a single project that tracks > developments of such closely tied parts? > > I am not saying that it is wrong to use submodule to track such > groups of source trees whose versions are very closely tied > together. At least not yet. > > I am just trying to find out what benefit you are getting out of > the submodule support, after rejecting one of the most visible > and advertised benefit of submodule support, which is to enable > binding "related but not that closely tied together" projects. At $dayjob, we are working on a codebase roughly the same size as current linux-kernel with about 8 years of history in CVS. I'm currently looking at how suitable git would be for our revision control purposes (and so far I'm lovin' it). The codebase is divided into CVS modules; most modules (aka. "core" modules) each have their own in-house maintainer and have internal releases with variable frequency. The other modules (aka. "platform/product" modules) each pull together a carefully chosen set of "core" modules as submodules, and add platform code to create - in the end - a complete product (with its own release frequency). Specifically: - All the modules required by the product must be present in the checkout before a build can be made - All the modules are independently developed, with different development/release timelines - The "core" people only focus on 1-2 modules at a time, but the "platform/product" people might make changes in _many_ modules during a workday. When investigating how to mesh this workflow with git, I naturally ended up with converting each CVS module to a git repository, and making the "platform/product" repos include the required "core" repos as submodules. This decision has the following effect from git's POV: - "superproject is not so super" in that _all_ required modules must be checked out before a build can be made. In other words: all the submodules in a repo are "interesting" - The modules are "related but not that closely tied together" since they follow separate development schedules, with separate releases, etc. - The "platform/product" people will most certainly want to have commands like "git diff", "git status", and maybe even "git log" and "git-commit" recurse into submodules. - The "core" people will probably not want "recurse-into-submodules" behaviour, although I can see places where it could be useful for them as well. A possible solution to the above problem is to add a '--recurse-into-submodules' option to all relevant git commands. At the same time, the actual implementation of submodule recursion should probably be kept in the vicinity of "git-submodule" (instead of spreading it across the other git commands). Probably unrealistic: Maybe we could solve the problem by adding "--recurse-into-submodules" to the toplevel 'git' command itself, and make it re-invoke itself recursively in each submodule. Hope this gives you insight into how _some_ people would like to use git's submodule support. Have fun! :) ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net - 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
