[rspec-devel] Git (was: [ANN] Lighthouse and Engine Yard sponsorships)
undees at gmail.com
Mon Nov 19 14:41:53 EST 2007
Many things that are good about Git are also good about Mercurial:
Mercurial performs comparably with Git, and seems even to be faster on Windows.
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).
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.
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.
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
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
> 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
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
> 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