One thing that git wins for me is interoperability. git's format-patch, send-email, apply and am subcommands make it very easy to interoperate with others using

One thing that git wins for me is interoperability. git's format-patch, send-email, apply and am subcommands make it very easy to interoperate with others using plain text patches on mailing lists for code review, etc. At this stage, isn't a "bzr vs. git vs. hg" question at all. It's just "look, it's a patch". I think this ease and ability to work losslessly with plain text patches gives git a clear advantage over bzr. This functionality makes it really easy for people who don't know git to interoperate with people who know it. Lossless interoperability with plain text is a key Unix principle (see TAOUP) and something that bzr lacks. With bzr, everybody involved with a project must use bzr. OTOH, a project that uses git can work more easily with a whole spectrum of people since sending a simple patch to a mailing list provides exactly the same ease of workflow to git-using developers as a complex multi-stage set of changes that is heavily reviewed and modified before being committed. (I don't know hg well enough to understand how it fits in here)