git, submodules and extensions

Hi, in general I'd really like to move to git+github. That aside I think the popular DVCSs (git, hg, bzr) won't work for PHP. Let me explain why oh and please correct me if I'm wrong - I'd be happy if this can be solved.[1] How does a DVCS work? (just the relevant part) The DVCS systems treat the whole tree as a single project tightly bound together. This has some benefits like moving files (or with some systems even chunks of files) around shouldn't break merges. But on the down-side one always has to checkout the whole project including all components. What's the problem with PHP here? In PHP we have our extensions. Over the recent years we got used to use PECL as incubator platform and as place to dump unmaintained extensions. For adding/dropping extensions to/from the core we did some cp/symlink magic on the CVS server and, by doing this, kept the commit history of the extensions - at least more or less. This isn't possible with the DVCSs as all files of the tree build the project. And we can't add directories including their history but the PHP tree would have to include all extensions we ever might want to add so everybody has to check them out... which gives us a big bunch of useless stuff there... what are the solutions offered by the DVCs and why won't they work? - Using script magic to rewrite history when adding/removing extensions. That's a really bad approach. - "submodules". Submodules are in a way similar to svn:external but instead of referencing the repository location a specific commit is referenced. This means after each commit to an extension the master project needs a commit to be informed about the new commit ID of the extension state. When doing that one also has to keep in mind to push all parts else other developers find a reference to an commit which isn't available. See [2] for an introduction to git submodules, including a 15 minutes webcast. The main purpose, as I see it, there is to have externally developed libraries and update them from time to time but treating these libs as truly external parts from the master project. Considering the amount of commits touching different extensions at once we have this seems rather troublesome. Possible solutions I see: - Add a bunch of scripts around the DVCS to help us here, sounds like no fun at all - Change our processes to develop extensions externally as much as possible and bundle "releases" from time to time. Pain for migration and quite bad for API changes (or when changing error messages which appear in different tests...) - Migrate to svn, as planned, then developers can use their git if they want. Anything unclear or other ideas? johannes [1] While writing this I talked to my brother who pointed me to http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension maybe that would work, so BitBucket+hg? :-) [2] http://book.git-scm.com/5_submodules.html