Junio C Hamano wrote:
...
Having said that, I do not necessarily agree that highly modular
projects would want to put everything in one git repository and
track everything as a whole unit.
And yet that's exactly how a lot of developers use CVS. You can argue
that some other way is better but when they move from CVS they're
looking for continuity of productivity which often means not radically
changing how they work. At least in the short term.
The primary audience of git, the kernel project, is reasonably
modular (although Andrew seems to be suffering from subsystem
I no longer believe that the Linux kernel developers are the "primary
audience". They are certainly an important and influential set of Git
users but there are also a lot of non kernel projects using Git. If not
now, there will soon be more non kernel Git users than kernel Git users.
[Nice description of how to work with the Linux kernel code base.]
[Nice description of one way a hypothetical project with dependencies on
libraries under active development could work.]
I think what truly huge but highly modular projects need is a
good support to lay-out check-outs from multiple subprojects,
each of which is managed in its own repository but has loose
(looser than the level of individual commits) version
dependency. That would need to solve three issues: (1) the
right versions from many repositories need to be checked out in
correct locations for a build, (2) after building and testing to
make sure they work together as a whole, these specific versions
from the subcomponent repositories need to be tagged to mark a
release, and (3) maybe a single large tarball that contains all
subprojects' checkout can be made easily.
>
So the issue may not be partial repository support, but support
for managing multiple projects.
There's no question that that may be better for some projects. But I
believe that the project members (or owners) should decide how they use
their tools.
-
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