On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:
One way we could create the forks would be to create a git repo for each package with two branches: the master branch that GHC builds, and a separate branch that tracks the main darcs repository, and is synced automatically whenever patches are pushed to the main darcs repo. We'd have to explicitly merge the tracking branch into the master branch from time to time. When we want to make changes locally, we can just commit them to the GHC branch and push the changes upstream in a batch later (and then we'd end up having to merge them back in to the GHC branch... but hopefully git's merge is clever enough to avoid manual intervention here). This is complicated and ugly of course; better suggestions welcome.
I don't think that this will work well. At some point we'll have to resolve conflicts that accumulate (by rebasing GHC-only patches after conflicting upstream patches come in? This may not be trivial, as the rebaser may not be familiar with the patches), and I suspect that the forks will end up diverging for significant periods of time, as there's little impetus to merge them. Even the current situation with Cabal is a bit of a pain, as it's easy to forget to push patches upstream as well as GHC's repo, and that's just with 2 repos of the same VCS. I actually think the original plan, where only the ghc repo (plus one or two others) is in git is preferable. You may have to use a different VCS for different subprojects, but after that it's downhill all the way. You don't have to worry about patches being converted from one VCS to another, moved to another repo, converted back and merged back into the first repo. I expect people will be using different VCSs for different /projects/, if not subprojects, anyway. Thanks Ian