It's time to consider again whether we should migrate GHC development from darcs to (probably) git.
From 2007 through 2009, I spent at least several months each doing real projects in each of darcs, hg, and git. After this experience I settled on git for all my personal projects and most of the projects done in my lab. I like git well enough to have migrated several
I'd be thrilled to see GHC migrate to git, and I'd be much more likely to make new contributions to the back end. The rest of this email contains observations about my own experience with source-code control. projects from legacy systems like CVS and (brace for it) RCS. I love the alleged features of darcs, but the reality of the performance is disappointing, and I once lost two week's work, which I had to painstakingly re-create by hand. I also have had difficulty learning the ancillary tools that support darcs. My workflow has never involved much cherry-picking, and I tried revising history ('rebasing') once and didn't like it. But I use git's "cheap branching and merging" workflow *very* heavily. (The only part of git I use more heavily is the graphical commit tool.) I left with a very poor impression of Mercurial. The simplicity is more apparent than real. Two grave faults are - Crucial functionality is provided by plugins in a configuration file. The configuration is not itself under revision control, and if different replicas have different configurations, results can be very confusing. - As far as I can tell, conflicts *must* be handled by a plugin. Every single one of these plugins requires a graphical tool, and I found each tool more confusing than the next. To make some merges work I had to get help from students---proving the old adage that the most clueless user of your software is not a graduate student; it is a tenured professor. There are plenty of other problems with Mercurial (commits don't have unique names; it doesn't cope well with big files; the graphical commit tool is a usability disaster; yada yada yada). After the initial settling-in period, I've been very happy with git. Don't get me wrong: git is a terrible tool---but it's the best of a bad breed. Anybody switching to git should be prepared: - Learning git is very unpleasant. I would say that the design is overly complex, but I see no evidence that any activity called 'designing the system' ever took place. (Example: in the world of git, 'push' and 'pull' are not dual.) Some of what makes git strange *does* make good design sense, but it is not explained well. (Example: it took me forever to understand that the mysterious 'index' is simply a device for packaging a group of changes into a single, atomic 'commit'.) - Git doesn't do what it says on the tin. In particular, certain combinations of actions are known to lead to breakage. Examples I have encountered personally include - Pushing to a repo that has changes in its working directory - Changing history in a repository not utterly private - Naming a branch 'head', which works fine on Unix and causes baffling failures on other filesystems Using git successfully requires that you avoid the vermin in the dark corners. But my top three activities---commit, publish, branch/merge---are all well supported and happen *quickly*. The graphical commit tool and history browser are reasonably good. A final comment: asking people to make the transition to git on their own is asking a lot. If GHC Central want to make this change, we should plan on some kind of tutorial, perhaps at the next Haskell Implementors' Workshop, to help people migrate. Norman