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