<h2>Tuesday, February 5, 2008</h2>
<h3><b>Use Mercurial, you Git</b>!</h3>

It's a land rush of revision control, I tell ya!  Among the <a href="http://en.wikipedia.org/wiki/Distributed_Version_Control_System">stable of eager candidates</a> for best-loved DVCS, <a href="http://git.or.cz">Git</a> and <a href="http://www.selenic.com/mercurial">Mercurial</a> seem to be the two tools capturing the most programmer heart-share for now.<br /><br />Git is admired because Linus Torvalds wrote it, but Mercurial is <em>better</em> because he didn't.<br /><br />Developers with refined sensibilities are in a tough spot right now.  We'd clearly like <em>something</em> to take the place of centralized tools like Subversion.  But why, oh why, does it have to be Git?  Let's examine the hype and the reality:<br /><h4><cite>"<a href="http://mjtsai.com/blog/2007/07/15/subversion-to-git/">The user interface is... not too bad</a>"</cite></h4><br /><em>False.</em>  I've heard dozens of authors whining about Git's usability.  I thought maybe they were overstating the case, or were just confused.  Then I tried Git.  If anything, they were being too kind.  Git polluted my /usr/bin with nearly <em>150</em> distinct binaries.  Mercurial has <em>one</em>.<br /><br />And if you think that you only need one or two of those commands for daily use, you're an optimist.  Check out the <a href="http://rubinius.lighthouseapp.com/projects/5089/using-git">"easy use" guide</a> from, by the way, an awesome Ruby project.  You're expected to juggle, depending on how you count them, about ten commands, just for day-to-day work.<br /><br /><blockquote>The <code>git rebase</code> command will save your changes away, update the topic branch, and then reapply them.... Warning! If you are sharing a branch, you must use: <code>git merge master</code>...  Rebase causes the commit layout to change and will confuse anyone you've shared this branch with.</blockquote><br /><br />Huh?  <a href="http://static.flickr.com/47/153603564_7281ad0588.jpg">Blah blah blah Ginger blah blah</a>.  For day-to-day use of Mercurial, you only need <code>hg fetch</code> to get code, and <code>hg commit</code> to give code.<br /><br />Git apologists will tell you that you need all these extra commands because Git was written with the "UNIX philosophy" of small tools that do only one thing, and do it really well.  Which brings us to our next myth.<br /><h4><cite>"<a href="http://git.or.cz/">Git... consists of many commands that do one thing well</a>"</cite></h4><br />O RLY?  From <a href="http://lwn.net/Articles/210045/">Git's own gurus</a>:<br /><br /><blockquote>Git checkout can do three separate things:<br /><ol><li>Change to a new head.</li><li>Revert changes to a small number of files.</li><li>Create a branch.</li></ol></blockquote><br />Those are pretty massively different tasks.  So much for "doing one thing."  I'll leave it as an exercise to the reader to debunk the "well" part.  Hint: try using git for any non-trivial project.<br /><br />Having lost the simplicity argument, Git-folk will try to tell you that the reason they dumped 150 pieces on your floor was so that you can build your own revision control software:<br /><h4><cite>"<a href="http://lwn.net/Articles/131312/">It's not an SCM.... I bet you could make a reasonable SCM on top of it, though</a>"</cite></h4><br />That was from Linus himself in the early days, though Git's recent admirers echo the same sentiment: <cite>"<a href="http://utsl.gen.nz/talks/git-svn/intro.html#wtf-why"><code>git</code> is first and foremost a toolkit for writing VCS systems</a>."</cite><br /><br />Who cares?  I ordered a version control system, not a toolkit for building one!  If I'd wanted building blocks for rolling my own, I'd have gone to Home Depot and bought a 1 and a 0.  You can build any software you like out of those, including a source control tool.<br /><br />Mercurial is a <em>working</em> DVCS right out of the box.  Why not use it?<br /><h4><cite>"<a href="http://wincent.com/a/about/wincent/weblog/archives/2007/11/one_of_the_thin.php">The model is rock solid and infallible because it is simple.</a>"</cite></h4><br /><em>Horseshit.</em>  I've even unwittingly <a href="http://rubyforge.org/pipermail/rspec-devel/2007-November/004583.html">repeated</a> this stinker myself.  Let's break it down a little.  <a href="http://utsl.gen.nz/talks/git-svn/intro.html#yay-simple">Quoth</a> the explainers (alongside a rat's nest of UML, to boot):<br /><br /><blockquote>The core Git filesystem can be explained as four types of objects: Blobs (files), Trees (directories), Commits and Tags.</blockquote><br /><br />Unfortunately, no, it can't.  The core of Git may well be <em>implemented</em> as four kinds of things.  But to get even the most basic tasks done, you need to know repositories, working trees, branches, remotes, masters, origins, index caches, and a bunch of other unexplained concepts.<br /><br />The manual pages are no help, for the same reason that "look it up" is no help to someone with a spelling question.  You have to know the name of the command before you can look it up.  And the commands are so obliquely named that there's no way to reason upward from what you know about the alleged "four kinds of objects" to make an educated guess as to which of the 150 commands you're supposed to use.<br /><h4><cite>"<a href="http://code.google.com/p/msysgit/">Git on Windows is only officially supported using Cygwin</a>"</cite></h4><br />This is another way of saying, "Git is not supported on Windows."<br /><br />I <em>like</em> Cygwin -- it's one of the few things that raises my (mandatory) Windows experience at work from "completely unbearable" to merely "excruciating."  But forcing my teammates to download and wrestle with the Cygwin setup, much less learn Bash, makes Git a complete non-starter in the one place where it could do me some good.<br /><br />Punting to Cygwin, in this day and age of awesome scripting languages (like <a href="http://www.python.org">the one Mercurial is based on</a>) is basically shouting to the world, "I can't be bothered to do my job properly."<br /><br />Actually, speaking of scripting, using Python is <em>exactly</em> why Mercurial can be so scriptable and extensible without dumping 150 inscrutable binaries into your /usr/bin.<br /><h4><cite>"<a href="http://kubasik.net/blog/2007/01/04/19/">git is reliable</a>"</cite></h4><br />I wanted to believe this.  Really, really wanted to believe it.  Unfortunately, Git fails at the most fundamental of source control tasks -- so much so that I'm going to have to take that up in a different post.<br /><br />The short version is that Git encourages and even requires you to tamper with your project's source history, and that is a recipe for disaster, not reliability.<br /><br />In summary: Git was created by a brilliant mind and is maintained by a posse of smart, motivated developers.  But it's a stinker.  Its power might justify the agonizing experience of using it, if there weren't any better alternatives.  There are.<br /><br />Code in good taste.  Use Mercurial.<br /><br /><strong>UPDATE</strong> <em>2008-2-6, 9 PM</em>.  In retrospect, a discussion on reliability should just be about data integrity: having a repository that's resistant to crashes and hardware failures and such.  The concerns in the final section -- discovering how to get data reliably out -- are not a pronouncement on the resilience of the repository format.  They have to deal with usability and coherence.  "Reliability" as a fuzzy human term is too broad a word here.

Posted by undees at 9:55 PM