Git Usability is On Par With Mercurial

In Five Features from Mercurial That Would Make Git Suck Less Geoffrey Grosenbach argues that Git is missing significant usability features that Mercurial has. I disagree on most points.

I must provide a few clarifications. I get that Git has a reputation for being arcane, but IMHO it is undeserved. You have valid points, but many of them are resolved in Git and the Git team is actively improving usability with every release.

An Intelligent Setup Command

How often does the average developer pre-create a repository with no content? I generally find myself creating a repository after I have a basic prototype or at least a basic project structure and directories on disk. I never create it beforehand.

However, this is a legitimate use case and one which – if sufficient demand exists – will be addressed.

In any case this is easily scripted and can even be added to the rails command so that your project gets a Git repository on creation.

Branches Everywhere

The Git example you give for deleting a branch is a valid way of deleting a branch in Git, but you can also do it easily as follows:

git branch -d feature_tweak

Deleting server branches (your demonstration) can be done with the somewhat arcane push nothing syntax git push origin :feature_tweak. I generally dislike the idea of deleting server branches and certainly of granting that privilege to anyone other than an administrator. I am glad the syntax is arcane, and I go even further on my Git servers by disallowing remote branch deletion entirely.

The increase in difficulty of git checkout -b feature_tweak over hg branch feature_tweak seems pretty minor to me. Committing changes is equally easy and pushing changes with git push origin is a minor usability difference and can be configured away.

Quick Local References

Here is where I stand firmly on Git’s side of this divide. I strongly disagree with the use of local revision numbers. Users coming from centralized SCMs will initially enjoy this feature and then become increasingly frustrated by it when they try to collaborate. Saying “Joe, the bug is in r3” is not going to work and providing it is an opening for wasting people’s time. In my experience, developers climatize to Git’s hashes fairly rapidly.

I’m going to go out on a limb and say that local ‘easy’ revision numbers aren’t even really useful to a sole developer. If you are tracking down a bug you are likely using a graphical historical analysis tool like gitk. That same tool lets you diff, checkout and otherwise work with that revision identifier without typing it (which is the only case where numeric revs seem useful to me).

Sensible Defaults

Reverting local changes is trivial with git checkout -f.

The lack of staging is a deal-breaker for me. In Mercurial I manually track the changes I make during a code review whereas Git tracks them for me because I staged the changes under review beforehand.

I agree with you on incremental commit. That strikes me as an extremely unwise feature.

Easy Serving

True on Windows. On any POSIX-compliant OS git daemon --base-path=. --export-all serves up all Git repositories in the directory over the Git protocol. This is a breath of fresh air compared to the infuriating leap I had to take to serve multiple Mercurial repos without resorting to a port per repo.

On Windows it takes about 5 minutes to set up Nginx and a post-update hook to run git update-server-info and serve over HTTP.

A server like Gitosis is a much better long-term solution than git-daemon. It integrates with your SSH server and is stupid simple to configure. I imagine equivalent servers exist for Mercurial now, but they certainly didn’t when I was using it.