Git: The Lean, Mean, Distributed Machine

With svn, I commit often, as long as the code builds and my own unit tests pass. If I need to make a lot of breaking changes, I use 'svn cp' to create a branch and then I can still leverage svn's merge tracking in keeping that branch up-to-date.

This seems like the same way I use git/hg, but without worrying about excessively divergent local/remote branches across machines -- I can see your branches, you can see mine, they're all centrally accessible by definition.

I've used distributed VC systems for quite a while, at least in the small. I find VC systems, databases, and the like verrrry interesting (due to a past life working in libraries), and an acquaintance of mine was the primary author of Monotone. I had already been keeping my home directory and /etc in svn, but that sounded far more interesting (it was also a full backup!). I tried it, and found using repository-as-a-whole versions more convenient than per-file versions. Later, I tried out hg, and felt it had a nicer interface / was easier to set up for common operations. (mtn assumed you cared to set up strong crypto auth for everything.) I was quite happy with Mercurial - it's a good system.

After using hg for a while (nine months or so?) I tried out git. It was still rough around the edges (the interface and documentation have since gotten better), but it had one major feature that stuck out - its ability to nonchalantly create and shuffle between several local, topical working branches in the same repository. To my knowledge, Mercurial still doesn't have a comparable feature, since their decisions about the core data structures make it awkward -- git saves the repo in terms of data snapshots, while hg saves the diffs (or perhaps vice versa, I forget). There was a major release where the hg team introduced "bookmarks", which were an attempts to emulate the git branching model, but you still had to be careful about copying them from one repo to another, etc. It had different trade-offs. I stopped paying attention around then. (If hg has since gained these, it would be a major point in its favor.)

That sounds overly negative towards hg, though. A major con of git is that the system is heavily skewed towards running on Unix. If you install it on Windows, it uses vim as the default editor for comments, it assumes you're used to man pages, etc. As a whole, the native behavior of the platform is an afterthought. Lots of little Unix-isms. Now, I can't blame them - I use OpenBSD at home, and strongly prefer old-school Unix in general. Also, developing any kind of system with the niceties that Unix provides and then porting it to Windows later is a big pain. Still, Mercurial's releases have consistently seemed to more evenly support Windows. I develop for Windows at work (in a field involving high-performance graphics and associated hardware), and, for my own circumstances, would choose Mercurial over git. Again, I should stress they're both a landslide better than any other systems I've seen.

Also, mercurial seems to place more emphasis on being simple for basic use, yet having a clean foundation for adding extensions. I haven't written any, or looked at it in a while, but it seemed like a good example of the different design styles - git was more powerful but scruffy, while mercurial was clean and more concerned with usability. (Whether this is an emergent property of git being written in C and shell scripts vs mercurial in Python with hotspots in C would be an interesting debate.)

I still use git for my home directory and personal projects, though most systems' flaws aren't a big deal for smaller projects. Feel free to experiment. If you're doing research prior to committing to one or the other for a massive project, switching really isn't a big deal until you have branches with months of churn. Unless you're working on the Linux kernel or an equally massive project (unlikely), it'd be far easier (in isolation - not counting retraining) to just pick one, use it for a couple months, articulate pros and cons, then switch and compare. They have quite a bit in common, and either would be vastly preferable to svn (ack!) or perforce (ACK!!!). You can't make an informed decision without trying either, and they're both quite good.

I looked into Darcs as another system that had interesting features and a pretty nice interface, but given the problems with bootstrapping an even remotely recent version of GHC on BSD (http://hackage.haskell.org/trac/ghc/ticket/1346), there's no way in hell I'd depend on Haskell for something as fundamental as VC.

Also, weird web2.0 juice nonwithstanding, it's a version control system, not a religion. It's a means to an end. You (everyone), you're using it because you're writing something, not because you're trying to be seen scribbling deep thoughts in a damn moleskine notebook.

Speaking as someone who's used both and prefers Mercurial:

* Git's branching philosophy (lots and lots of branches, only one active at a time) can be handy. But Mercurial's philosophy (not quite so many branches, and usually as separate clones so you can work on more than one side-by-side) is, I've found, usually better.

* Git's much more encouraging of editing history up to the point where you share code with someone else. Mercurial will let you do that if you really want to, but it's discouraged; the only "easy" way is limited to undoing the last commit. Git seems to encourage committing much, much more often and not particularly caring about the repository history until you're ready to share with someone else (at which point you just selectively rewrite the history to look sensible). Mercurial seems to encourage committing in logical chunks so the repo history is clear and sensible the whole time (but again, if you really really want to do the Git-style stuff, you can).

* Mercurial seems to me, personally, to be a bit more logical in terms of choosing good defaults and exposing abstractions. Git's choices for default behaviors have been criticized even by its fans, and it tends to throw a lot of its inner workings at you on a regular basis, even if you don't really care much.

But, again, this is only my own personal opinion; undoubtedly others will disagree with it.

When I last used Mercurial heavily (around a year ago), its branching was weak so the user model tended to be clone to create a new repo as a branch rather than branching within a repo. Logically, this is the same, but practically it is less convenient... it tends to create multiple directory pollution and then you forget what is in which directory (especially when you have CRS disease). I understand Mercurial branching is catching up or caught up with git.

Mercurial is pure Python (sorta), which makes it more portable (sorta) but slower (sorta). Git is written in C, which makes it faster (almost always), but assumes a "reasonable" POSIXish OS environment, making it hard to port to Windows (solved now).

TortoiseHg is great on Windows. I have played a little with TortoiseGit - it appears to be as good as TortoiseHg on Windows, but that is a recent development.

Git has some killer features, starting with its near magical merging. As Linus points out, branching is easy - it is the merging that is difficult. Hg is on par with merging, so that isn't a big discriminator.

A unique feature of git is the "index" staging mechanism. This is very handy to pick out certain changes (with the "interactive" mode, even down to the line-in-a-file level) and check just those changes into your repository without having to either update everything as a lump or jump hoops to separate wanted and unwanted changes.

Another really nice feature is git's "interactive" mode which allows major patch rework/rearrangement - you can split, merge (squash), and reorder patches. This allows you to be anal-retentive on checking in your changes frequently and then rationalizing the forest of changes before pushing it upstream. (From what I've read, while it looks like you are "changing" history, in the bowels of the git metadata, all the state and sequence information is preserved.)

Git's rebase is very nice and very useful if used with discretion. Again, it looks like Hg has a rebase plugin now.

Personally, I prefer git because it is the repository for the open source projects I'm involved in and because my perception is that it is more popular and growing faster. If your development is in the Python world, you probably will prefer Hg for the same reasons. ;-)

The really good news is that you can move from SVN to Hg or git easily and you can move between Hg and git bidirectionally with only the conversion time as a penalty without losing any information. This means that, even if you pick the "wrong" DVCS, you can "recover" easily.

Some of gits front end is (even now) a bit weak, but, it's also quite complete (really) and insanely powerful (for better or worse, you can really shoot yourself in the foot with it, if you poke too much).

There are things that are commonly in use that people shoot themselves with all the time (like stash - which is really an antipattern when you have such cheap branching (hint: branch & commit never causes problems, and rebase / cherry-pick help you squash temp stuff)). You can find anti-patterns in any software though, and I recommend you simply use both for a while, I think anyone unbiased will generally agree they've very very comparable.

If you have a brain cell or two, neither of these systems are going to be a major bottleneck to use, despite what folks might say about their UIs etc.

Git is a little faster at doing some tasks, but this isn't going to really matter to you unless you're managing large repositories. Gits recent popularity growth means there's some neat tools out there too, depending on your platform, and preferences.

As far as windows support goes for git, I have to help less technically minded non-developers use git on windows on a fairly frequent basis, and msysgit works just fine there. You'll want to be aware of details of SSH & key management, and debug with ssh first before debugging with git. That's standard debugging though, and not really anything to do with git, or windows, but the lack of commonality of these tools on the platform. Again, a few brain cells correctly engaged very rapidly get past any such niggles if you're being pragmatic.