Improving the Git Windows experience: Downloads

I love Git. It’s very powerful tool that lets me bend my repository to my will, with commands and features that blow the other source control providers I’ve used out of the water.

However, the tooling just doesn’t do it justice. From the download, installation, integration and CLI experience, it always feels like (in Windows land) that you’re playing in someone else’s back yard.

Over the next few posts, I’m going to compare the experience of using Git with that of Mercurial, who has, in my opinion, lesser features, but a much MUCH better experience.

The Mercurial download experience

Let’s look at searching and downloading the Mercurial client. When I google “Mercurial” or “Mercurial Windows” or “Mercurial Windows Download” or variants, two of the top results are the official Mercurial home page, or the official Windows client, TortoiseHg.

From there, I want to download Mercurial. Both websites offer very clear ways of doing so. The Mercurial site:


And the Tortoise Hg site:


Two very large “download buttons”. These buttons are interesting in that:

  • They link directly to the file to be downloaded.
  • They both link to the exact same installer
  • They know what OS you’re using, and display the correct installer accordingly

TortoiseHg is the official Hg client for Windows, and includes:

  • The command line interface
  • Windows Explorer integration
  • Visual tools (Workbench etc.)
  • Visual Studio integration
  • Merge tools

It’s a completely out-of-the box client that includes EVERYTHING that you might need to run Mercurial, all in one package, and consistently presented to the end user.

Next, let’s look at the Git download experience.

The Git download experience

When searching for Git downloads, you’re primarily directed to one of two sites – the official Git site, or the official Git tools site for Windows, hosted on Google Code (and also GitHub, curiously enough). The Git site is clean enough:


Except I have 3 download links instead of one. Not a big deal most of the time, but already choices are presented to the end user over the Mercurial site. Clicking on the Windows link takes me to this page:


Instead of linking me directly to the installer file to download immediately, I’m directed to the downloads page of the Google Code site, where I am presented with yet even more options. There is nothing in this screen that screams “THIS IS THE INSTALLER YOU WANT IGNORE THE OTHERS”. As someone new to Git, how do I know which to choose? Probably the first one, and most people would choose the first one, but presenting choices here is pointless and confusing.

Not to mention, I’m whisked away to a site that has nothing to do with the original Git site. The official Git site didn’t mention “msysgit” but now I’m on the msysgit Google Code site. Even more confusing is that the file has the name “preview” in it, and the installer is labeled as “Beta”. So is the right one or not? I might be inclined to search for the last “good” release and not a beta/preview one.

The Git installer is also less featured than the Mercurial one. The official Git Windows tools include:

  • Windows Explorer integration (very limited)
  • A CLI through the Git Bash or directly in a command prompt
  • Visual tools (OK tools)

However, I typically don’t point folks to the official Git client. Instead, I point them to Git Extensions, a more fully featured toolset that includes:

  • Windows Explorer integration
  • Visual Studio integration
  • Richer visual tools
  • Bundled merge tool
  • Bundled Git installer

This isn’t the official Git Windows client, so you basically have to know it exists to find it. Almost none of the online tutorials recommend it, even though it matches much more closely to what Mercurial provides out of the box.

Improving the Git download experience

In two easy steps:

  • Have the official Windows client be as full featured as the Hg one. Could just start with Git Extensions and go from there.
  • Copy the Mercurial website’s behavior

In short, prefer Simplicity over Choices. Have defaults, and obvious ways to get to the non-defaults.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in git, Mercurial. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Kjnilsson

    Heh – exactly the experience most people have when going from Mercurial to git. The worst thing for me was when I did git merge master expecting it to behave roughly like Mercurial. It didn’t and I messed up the merge quite badly.

  • Mihai Lazar

    Thank you!

  • You can install Hg/Tortoise and Git via Chocolatey Package Manager ( ).  Both make the experience on both but git especially nicer.

  • IMO it’s about the eco systems these systems were developed in. Windows is about the GUI, *nix is about the command line. The majority of git users wouldn’t even go to a website to get it.

    • I’d say Windows is about one-click install, *nix is about presenting lots of non-obvious choices, so that I have to learn the damn thing and everything around it even before I install it. Oh, and about scaring off the stupid Windows users, too.

      IMO, it’s a huge win that somebody bothered to make an installer. We’re lucky we don’t have to set up the environment variables and install Python just to run some setup script and get an esoteric error message (because we didn’t know we should have uncommented some line deep inside some ini file).

      • Truth.

      • Anon

         Your reply would make sense if installing it on Linux wasn’t 100 times easier than on Windows. Honestly, most Linux users don’t really care about the GUI interface because they’re smart enough to learn the CLI and realize that it is faster than GUI once you have done so. For the commands that could be simpler in GUI, there’s usually an interface (git difftool, git add -i, etc.)

        People don’t use GUI on Linux because they’re smarter than the average Windows users. I used Git Extensiosn before and I decided not to anymore because it wasn’t efficient.

        •  Just as I said, the familiar “us smarter than them” attitude.

        • Jock Murphy

          Please document the correlation between smartness and using the CLI.

          Because I don’t think you can.  I cut my teeth on *nix back in the mid 80s and have had a some kind of *nix/linux in my house since then.  I love me some command line.

          But guess what?  I also love the GUI, and I personally don’t believe that SCM is better suited to the CLI.  Different people have different need and work better in different ways.  Just in the same way that people learn in different ways.

          One is not superior to the other.  And when you make a stupid claim like the one you did, all you are really saying is “I am an elitist who only wants to deal with people who only think like me”

  • phil jay

    I heard they’re working on new Github tools for Windows..

    • Anonymous

      Yes…thanks to Phil Haack moving over to GitHub…

  • Nolan Egly

    I just had to install Mercurial, and when I searched for “mercurial download” the second link (the first was a wiki page) was:  Mac?  Python?  Source, or binary?

    I ended up with just the command line tools without Tortoise and had to grab it separately.

    I do agree with your observations on git, especially that the Git Extensions is not well known enough; it’s much better than TortoiseGit.

  • Anonymous

    Just started working with git, actually github but even there it’s nearly as confusing.  Although github does have some pages which walk you through the process.  Even after you find the right file to download, there are some options to select in the install which aren’t readily apparent what you should pick.

    Fortunately I used to do a lot of Unix work and bash isn’t new to me.

  • Russell

    Is it the attitude of the developers? In open source, I seem to see this a lot. I could be wrong, but it seems to me that tools to make things easier are looked down upon. If you don’t know the command line or which choices to make or you don’t want to compile the code, etc., then you’re an ignorant neophyte not deserving of the tool. Anytime you suggest “easier” then you’re not a real programmer. But that’s what I look for . . . tools to make my life easier, coding faster, and my workday less stressful. Some coders seem to relish the difficulty . . . look how difficult this is . . . I can do it because I’m so smart. And then there’s the volunteer aspect. Even if the developers don’t have the aforementioned attitude, they don’t have lots of time to churn out refined tools. You can only volunteer so much before you starve to death. Sometimes commercial software is the better choice. Not always, but sometimes. As the projects get smaller, these issues get bigger. I don’t bother with small open source code – I’ve found support is almost nonexistent. Can’t blame them – if I was putting out open source software, I’d have the same pressures. Got to do something to make a living and it would take away from coding and support time on the free code.

  • Scott Chacon

    It’s weird to me that you would spend all of this time writing this big blog post on all of this instead of just fixing it and sending me a pull request which probably would have taken half as much time as building and presenting your case here.

    I agree with most of this and would be happy to make it happen, but I haven’t had the time lately to figure out how to do it as nicely as I would like.  The main issue is that the msysgit releases are on Google Downloads, which afaik don’t have an API, so I can’t automate the choosing of the latest binary (at least not as reliably as I would like) or even really figure out what the URL for the latest binary would be.  The msys team is moving a lot of their stuff over to GitHub, which does have a full featured API for downloads, so maybe it will become easier soon if they decide to move their downloads too.

    Git Extensions is not a bad idea, but it is a repackaging, so it will be behind (for instance the current download will install 1.7.8, where msys will install 1.7.9 which actually has some important things in it).  It also assumes Git endorses that as sort of the “official” version, which is not true – there are things in that package that are not core git and are not universally liked.  I would prefer linking to a clean packaging of core git code.  (Also, you don’t have to know it exists to find it, it’s listed in the ‘Tools and Hosting’ section of the Git website)

    I would love to solve these problems, and in time I probably will.  However, in the meantime, if you want actually to fix any of this, a pull request is much more powerful than a complaint.

    • I don’t see it as a complaint, more like a thoughtful analysis, with some valuable suggestions. I know that Mr.Bogard spends a lot of time with his own OS project, so it’s not fair to demand him to send a pull request (which wouldn’t fix some issues that you say cannot be fixed at this moment).

    • Describing this in public provides insight for others who might not see these issues that such user experiences offer and potentially help in avoiding it in the future. It’s not always necessarily about fixing one specific project or equating the time it takes to write a post vs sending a patch.

    • T.J. Crowder

      Aside from the points made by Hadi and Artëm, writing this blog post probably took as much as 45 minutes; doing the work of updating the git homepage in line with the principals therein would probably take, what, a full day? And then the pull would be rejected, because the post describes doing some things you’ve said you don’t want to do (which is fine). Seems like a powerful reason for posting rather than doing a pull request. And it never hurts to underscore the “prefer simplicity” message… :-)

  • Ttt

    Totally agree, but there are some really good git tutorials out there. The windows site needs to bring this info together

  • David Huntley

    Of course,..if you want a great DVCS on Windows then there’s always Plastic SCM.  I’ve moved from SS to TFS,  SVN, Merc and Git in the past 2 years and found Plastic to be just as good as Git is on *nix and better than TFS for Windows because of it’s distributed nature.  It’s free up to 15 devs now and the tooling and integration is awesome,…WELL worth a try if you’ve never seen it. (and no, I don’t work for them :-) )

  • Mark Heath

    great post. At least it would appear that the default editor for commit messages is now notepad istead of vi (which always requires me to google for the key combination required to get out)

  • Pingback: OSS Rules of Engagement | Jimmy Bogard's Blog()

  • Anonymous

    By the way, Paul Betts and I are going to work with a designer who’s offered to contribute some of his time and see if we can’t come up with a nice landing page for msysgit that help address some of these issues. Thanks for the post Jimmy!

  • Anonymous

    How about this? Just use chocolatey and you don’t have to worry about it…. 

     cinst msysgit

    Boom. Done.

    • Anonymous

      Or if you prefer – cinst gitextensions (which will install msysgit)

    • Anonymous

      By the way, I linked your article to the story of why chocolatey -

    • Except that you cannot find any mention about it on the official site.

      • Anonymous

        I can’t think of a single product in mind that mentions the chocolatey pkg mgr (except ILMerge). But then again, I don’t see them pointing to ninite or other pkg mgrs either. 

        And it’s not likely they will anytime in the future either…

        My point is that pkg mgrs are after thoughts for windows… 

  • Anonymous
  • Anonymous

    Everything you said about improving experience at the end applies to not only git and not only software development. Awesome.