Why git isn’t better
Scott Chacon should know better than to maintain a site like http://whygitisbetterthanx.com/. He’s the author of hg-git.
If you’re not using either Git or Mercurial (hg) (or Bazaar or some other appropriate DVCS), you should be. I prefer hg, but I think git is generally fine. Scott Chacon, however, thinks that git is unquestionably better than hg, for three specific reasons I intend to counter here, with reference to Geoffrey Grosenbach’s recent post on the matter.
Update 2 Sep 2009: See this post by Steve Losh for more on the branching issue.
Update 2 Oct 2009: Scott Chacon is not an idiot (nor did I mean to even imply that he was!), and has demonstrated his not-idiotness by apologizing “for being a tool” (his words).
<span id="more-1325"></span>
<ol>
Cheap Local Branching
Really? This is supposed to be an advantage git has over hg? I’ll just point to the Branches Everywhere section of Geoffrey’s post::
Mercurial branches are not only easy to make, they are also easy to use! They go everywhere the repository does. You don’t have to worry about tracking branches or weird pushes to get them onto your remote repository. …
Once you’re done, close the branch and they disappear.
And that only describes named branches, which you don’t need to use. Bare clones are (disk-space and wall-time) cheap.
The Staging Area
This one is a great example of git making the common case more complex than the less-frequent case. Most often, when I complete a feature or bugfix, I want to check in all the files I’ve just been working on. Having to ‘stage’ them all gets in the way—even if it is a single-letter command-line switch.
The case of wanting to check in only some changes in a file is handled nicely by the shelve extension. Just shelve the ones you don’t want to appear in the commit, then unshelve them afterwards. This has the added advantage of avoiding the serious issue that Geoffrey brings up:
… being able to commit just one part of a file … means you’re committing a changeset that you’ve never used, never run tests against.
If you shelve the unwanted changes instead, you can run your tests against what you’ll actually be committing.
GitHub
Yes, it’s a clone of GitHub for hg. But it also rocks. In particular, Scott’s claim that “this type of community is simply not available with any of the other SCMs” is proven false by bitbucket’s existence.
I don’t mean to say that hg is better than git. It has its weaknesses as well—but these aren’t them.
No comments
Jump to comment form | comments rss [?] | trackback uri [?]