No subject

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
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