At the risk of starting a darcs vs. git discussion I have some
thoughts about the tension.
On Wed, Oct 6, 2010 at 12:10 PM, Don Stewart
== GHC ==
* ghc status + 50% split in room on moving ghc from darcs to git.
I don't see that tension resolving itself easily. VCS tools are subject to "network effects". If your friends are using VCS Foo and you want to work with them, then you adopt Foo too. It's also a part of the toolchain that people tend to have strong opinions about. One possible way to lessen the tension would be good vcs bridge tools. There have been numerous repo converter projects, some even supporting synchronization. There is already a git-svn tool. Maybe there should be a git-darcs (and a darcs-git)? If a git hacker out there wants to add darcs support to git, I'd certainly be willing to help them get started. Pushing on this a bit more, I'm fairly convinced that darcs and git are dual to each other in terms of underlying models. As such, I have some ideas on how to unify them/convert between models. Unfortunately, actually having something to use is very far off as the ideas themselves are still immature. As far as I can tell, the main reasons to vote for git: * Some people simply love git and want to use it for every project * Git is faster and/or more memory efficient for some operations (most? all?) * Github As far as I can tell, the main reasons to vote for darcs: * GHC already uses it (inertia) * The windows support appears to be more mature (I admit, this is somewhat subjective as neither has a spotless record here) * Key players, such as the Simons, prefer the darcs UI over the git UI (i.e., some people prefer darcs) * Darcs 2.x has consistently improved in robustness and efficiency over the last several years, continues to improve, and incorporates ideas from git. (there is currently an experimental 'rebase' command in the development branch of darcs) * Cherry picking Note: I didn't mention feature branches as a reason to prefer one over the other. Both darcs and git support this. Git uses in-repo branches and with darcs you can simply do a local lazy get. Some people prefer one mechanism over the other, but the point is they both support the workflow. I also didn't mention server side bare repos. I'm trying to focus on the context of what GHC should use and as Simon Marlow points out, the current darcs workflow is scaling well so it seems that the lack of darcs bare repos is not an issue at the moment. I would like to see the tension of darcs vs git for GHC reduced. I think it ultimately amounts to: Contributors need to be able to use the one they prefer, instead of being forced to use the one GHC devs use. Us haskellers could build a tool to solve that problem.
+ bug reports and interaction load with ghc
I'd love to get elaboration on this point.
+ well documented workflow for lightweight changes + heavy weight process for major work. + bugs, tickets. + Simon Marlow "contributions are going up, and process is working well"
That's reassuring. Is their workflow documented for the benefit of other Haskell projects and the greater FOSS community in general? Thanks, Jason