[rspec-devel] Git (was: [ANN] Lighthouse and Engine Yard sponsorships)

Ian Dees undees at gmail.com
Mon Nov 19 14:41:53 EST 2007

Hi, Wincent.

Many things that are good about Git are also good about Mercurial:

> speed

Mercurial performs comparably with Git, and seems even to be faster on Windows.

> elegance

Elegance is hard to define.  Git does indeed have an
easy-to-understand mental model, but so does Mercurial.  Mercurial,
though, also has a simpler command set and is written in clean Python
code (rather than a mishmash of clean C and clean shell scripts).

> robustness

Operations in Mercurial are atomic.  During writes, the metadata is
the last thing to get updated, so you can kill the process in
mid-commit, mid-merge, mid-update, etc., and the source will still be
in a consistent state.  I've brutally stopped commits, tried to shoot
myself in the foot by merging the wrong thing, and so on -- Mercurial
has always rescued me.

> maturity

Mercurial and Git were started at about the same time, for the same
reason (the revocation of the BitKeeper license).

> tool set

Mercurial has hgk, a port of Git's quite nice gitk GUI.  Everything
else I've needed has been abundantly available either as part of the
extensions that ship with Mercurial, or as an easy-to-find Open Source
add-on (kdiff3, TortoiseHg, etc.).  And until there's a "TortoiseGit,"
no one, but no one, will match the TortoiseCVS/TortoiseSVN/TortoiseHg
shell integration for ease of use on Windows.

> optimized, distributed workflow

I think most distributed SCMs have this, by definition.  Offline work,
patch queues, and cherry-picking are par for the course.

> extensibility

I'd have to give Mercurial the win here; in addition to hooks,
Mercurial has an easy extension model and is written in a scripting

> import

I've imported a personal SVN repository into Mercurial without too
much fuss, but I admit it was a simple one -- no branches or merges.

I'll cede you the points on community talent (Linus) and community
activity (bustling).  "Bright future," I dunno.  I hope both projects
have that.

> The most oft-cited argument against Git that I've heard is about its
> Windows support.

And the most oft-cited argument against living underwater is that it's
hard to hold your breath for a long time.  It's oft-cited for a
reason.  ;-)

Lack of Windows support is one common objection, but by no means the
only one.  The complicated interface (I'm just talking command-line
here) is another, as is the hodgepodge of implementation languages and
the perceived abrasiveness of (some of) its supporters.

> Git is officially supported on Windows under the Cygwin environment;

... which is another way of saying "Git isn't officially supported on
Windows."  Requiring end users to jump through all the hoops of
installing Cygwin and making them use bash (though I quite like both
myself) would make Git an absolute non-starter if I tried to push it
in my shop.  I'm glad to hear they're working on it, but Mercurial is
ready now.

> And Linus sparked a lot of interest in Git earlier this year with this
> flame-y Google talk (not too much technical discussion, mostly high-
> level overview):

Actually, that Linus talk was the one that convinced me to go to
Mercurial (which, as he notes in the talk, is the only other SCM he
considers a worthy alternative to Git).

Ultimately, it's not a slam-dunk for Git or Mercurial; RSpec could
probably do fine with either.  But I know which one I'd rather use,
and that's the one that gives me joy on a daily basis.


More information about the rspec-devel mailing list