Why is the .NET Community Using git?

(Disclaimer: I have minimal experience with DVCSs.  The title of this post is an honest question, and if I’ve made any incorrect asummptions or gotten something just flat-out wrong, I’d love to be corrected.  Please let me know in the comments!)

My friend David Mohundro wrote a post the other day with some great tips on using git on Windows.  That got me thinking about why the .NET open-source community has started to coalesce around git as its source control tool of choice.  I know git is the new hotness, but it’s not the only distributed version control system (DVCS) out there.  In particular, I wonder why Mercurial hasn’t caught on.  It’s a DVCS like git, is more compatible with Windows, and is easier for new users to learn (by virtue of simply having fewer commands and using terminology closer to that of older VCSs).

I know that git can be used on Windows using a project called “msysgit,” but the fact that that project exists at all should tell us something about git.  Git was developed by Linus Torvalds to be used when working on the Linux kernel, using a combination of C and Linux shell scripts.  The maintainers have very little motivation to make git cross-platform, since it already solves the problem it was designed to solve.  In addition, the maintainers of the msysgit project have not always been very interested in solving the problems of their users, as evidenced by comments like these.

Mercurial, on the other hand, is designed to be cross-platform in the first place  (from the about page on the Mercurial site:  “Mercurial was designed with platform independence in mind.”).  It seems to me that it ought to be a more natural fit for people developing on the Windows platform.  And it’s not as if it’s some obscure bit of technology used by only a few people; large organizations (e.g. Mozilla and the Python Software Foundation) as well as smaller ones are using it.  On top of that, Codeplex (Microsoft’s open-source project hosting site) now supports Mercurial, and so does Google Code.  So why git instead of Mercurial?

I have a couple of theories about why lots of .NET devs have made this choice, but please keep in mind the disclaimer at the top of this post.

  1. Features – Git does have a few features that Mercurial lacks.  Most notably, it has an index or “staging area”, which allows you to have more control of what a commit will look like.  Local branching is also a bit different, since git doesn’t actually create a copy of all the files in the repository when you create a branch.  It would seem to me, though, that the main feature that attracts OSS devs to git is its distributed nature, which fits very well with the OSS workflow, and which Mercurial shares.
  2. A Superior Project Hosting Site in GitHub – Almost immediately after its launch, GitHub became the place to be for open source projects, and for good reason.  The site offers a great user experience, and lots of tools to make maintaining a project easier, such as the network graph and pull requests.  Bitbucket aims to do the same for Mercurial, and has some of the same features, but hasn’t caught on the way GitHub has. (Circular logic there, maybe? Oh, well.)
  3. Rails Envy

I hate to say it, but this last one is the one that I suspect may be closest to the truth.   .NET developers, especially ones heavily involved in open source software, have always had a bit of an inferiority complex.  At first we felt inferior to Java devs, who had a big head start on figuring out the limitations of their platform, which led to development of lots of patterns and a plethora of open source tools at their disposal (their culture was a lot more amenable to open source a lot earlier than the Microsoft culture was).  The similarities between the .NET and Java platforms and languages was to the .NET community’s advantage; it was straightforward to directly port many of the more useful Java tools, and the patterns translated easily.

A few years ago, a shift in who we compared ourselves to began.  We saw how much less friction there was when using a framework like Rails and a malleable language like Ruby.  So, as we did before, the .NET OSS community began adopting the tools and patterns used by those we envied admired.  Some of these things translated pretty well.  The principle of convention over configuration, for example, has nothing to do with platforms; it’s just a mind shift that .NET OSS devs were willing and eager to make.  The tools, however, can’t always make the jump.  Windows has always been a second-class citizen when it comes to Rails development (DHH has made his disdain for the platform quite clear), and that tends to create a self-perpetuating cycle.  The existing Rails devs don’t put much effort into making things like tools and plugins cross-platform, so the experience sucks for devs on Windows, who finally give up and switch to a Mac (or at least do their Rails development on a Linux VM), so nobody’s clamoring for the tools to work on Windows.  Regardless, many .NET OSS devs tend to use a lot of the same tools as Rails devs.  Things like rake, Cucumber, and, of course, git.  It sometimes seems like we’re bending over backwards to make tools that weren’t designed for our environment work for us anyway (e.g. msysgit).

So are the few extra features in git or the better UX on GitHub really enough to justify the friction of using git on Windows, or is it just a cargo-cult mentality?  As I said, I have very little experience with either git or Mercurial, so I may be missing something big.  I’d love to hear from someone who has experience with both DVCSs to set me straight.

In any case, I hope that at some point, we as .NET developers can get over our inferiority complex and just feel comfortable in our own skin.  That doesn’t mean using the Microsoft tool every time, but acknowledging that sometimes, just because a tool is useful in one environment, doesn’t mean it’s a better fit (let alone the aesthetically superior choice) for ours.

3 thoughts on “Why is the .NET Community Using git?

  1. Dscho

    This is a blatant misrepresentation of the msysGit project, and you should be ashamed for it.

    It should be clear – even after only the slightest hint of research – that the ratio of msysGit users vs developers is well over 10.000. It should be even more clear, then, that it is just not possible to take care of all the user requests, especially those that ask for feature enhancements. And then, there are comments like yours, which are not exactly motivating for people who work for no money, so it is really the fault of comments like yours when you get a negative answer in the form as the one you “linked to”.

    To be really honest: your blog post is the best proof that the form of those answers is not always unmerited.

  2. Brian Post author


    I see that you are one of the committers on the msysGit project, so you obviously have a strong emotional investment in the project. I apologize if my comments offended you. You and the other maintainers of msysGit have put a lot of time and effort into the project, and you should be commended for it.

    It’s completely understandable that you and the rest of the team won’t be able to respond to every single bug and feature request, especially not immediately. As you said, this is something you have to work on in your free time, which I’m sure is quite limited, and you get to what you can get to.

    However, I think you may be overreacting a bit. It’s not as if for the entire post I was railing against the msysGit committers and community; I barely mentioned it. And besides, my blog is not exactly required reading in any tech community, so you can be pretty sure that I won’t be “discouraging” anyone from working on msysGit. I imagine the way you found it in the first place was by using Google Alerts or a similar tool, without which it would never have come to your attention. And besides, the thrust of my assertion wasn’t about the number of features the msysGit team are able to address, but the attitude with which they respond to such requests. If the tone of your comment here is any indication, the responses I linked to may be representative after all.

    So, ashamed? Not really. If something as innocuous as what I said is enough to make you not want to work on msysGit, you may want to examine your motivations for working on the project.


Leave a Reply

Your email address will not be published. Required fields are marked *