Junio C Hamano schrieb:
"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?
Because the a monolithic project is just too large? Think of KDE!
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.
In KDE, the supermodule will actually just be a container that binds the
submodules together. The essential development will happen in the
submodules, and the supermodule will receive a commit quite frequently. In
this case, there will often be only a few or a few dozen commits listed, and
I anticipate that the integrator who is going to make the commit (to the
supermodule) will probably like the summary. So I'm all for it.
-- Hannes
-
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
