Question

Everywhere I read about Mercurial and Git they generally throw in a line or two which implies Git has limited ability on Windows (because of some Shell scrips cannot be ported, etc.) but I’ve never come across some page which explicitly mentions them. And most pages are a tad old.

What are the limitations of Git on Windows in terms of functionality? And does having to run Git on MinGW and MSYS on Windows have performance limitations?

Answer 1

EDIT: So it’s 2016, six years on from when I wrote the original answer below. I’ve used git and mercurial heavily for several years now, and I’ve been developing on a mac for several years too. I’ve become very familiar and comfortable with git usage on the command line, but for day-to-day work I use SourceTree from Atlassian. This is not an advertisement, just a note to update this answer. SourceTree is a double abstraction: the same ui for for git/hg, and the same ui for Windows/Mac. When you have to switch platforms and projects often, this becomes very attractive.

Having written a guide to setting up both client and server for Git on Windows, I have a pretty good idea of what one can expect. Also, my primary repository (.git folder) is ~260MB of source, so it is really not a trivial performance test for day-to-day Git work on Windows.

My general impression is that Git on windows is very fast for the vast majority of situations one is likely to encounter, with one really huge exception: git gui blame -C -C. By default, git will not blame on files beyond file rename boundaries, and the extra -C -C arguments must be passed to enable that to happen, but then things can really slow down. It takes 17 minutes on modern hardware to produce a complete annotation of one of our larger ~20 kloc source files. That delay can really break your concentration.

Regarding cygwin:

I only tried this once, and not for anything significant. I really wanted a native solution. By all accounts, git on cygwin works well enough.

Regarding TortoiseGit

Frank Li has done tremendous work bringing the now-familiar UI to the Git world. TortoiseGit started up very quicky because most of the UI was available from TortoiseSVN (and other tools like TortoiseMerge), and I have worked with this interface a great deal. In general, it allows one to get going with Git very quickly if you are familiar with TortoiseSVN. The developer has gone to great pains to use terms from the TortoiseSVN world and map them to git commands. For instance, a revert really performs a git checkout <file> under the hood.

In general, working with Git this way has been pretty seamless, and I must admit to having learned Git while using the TortoiseGit interface: and it must be conceded that this was a hindrance to my education. The TortoiseSVN-like log viewer doesn’t really work for a distributed-vcs workflow (it works well enough it you use Git as if it were SVN), and you only find this out later because the problems only come in when there are many, many development branches (the gitk tool is much better at handling this display). And the other issue is that even after using TortoiseGit for many months, I still didn’t know even the most basic git commands. There is nothing really wrong with TortoiseGit, and bugs get fixed impressively quickly when they do occur; the main problem seems to be a design issue (possibly more than one) in the UI, something that the gitk and git gui developers have worked out because of a longer development history, or a more intimate knowledge of idiomatic git usage, or something like that.

Regarding command-line use:

The MSYS git development team are the ones who really should be thanked for even bothering to do all the work they did, and without their support it is likely the mingw git branch would never even have been merged with mainline.

I have now begun using msysgit, as is, in the Git Bash shell, as my only git interface for a few weeks. My impression is that, although the initial learning seems more difficult, once that knowledge has been gained, everything else becomes easier. This reference is, in my opinion, one of the really better references learning git on the command line.

Speaking as a Git user on Windows, and coming from an extended experience using the TortoiseGit interface to git, this is a summary of my workflow, which covers >95% of what is needed (all in Git Bash, not the Windows command shell (cmd)):

• Check for Modifications

  git status

• Switch branch

  git checkout some-feature-branch

• Fetch

  git fetch

• Show Log (the & detaches the gitk process from the shell, so that the shell doesn’t wait for gitk to be closed before allowing more commands)

  gitk &

• Commit: either

  • Simple commit:

    git commit -a -m “This is my commit message”

  • Complex, multiple successive commits:

    git gui

• Push to branch: master

  git push origin master

• Merge (e.g. after Fetch)

  git merge origin/master

I haven’t had to do any conflict-resolution yet, but I’ll figure that out when the time comes (comments welcome :).

EDIT: For conflict resolution, kdiff3 is the way to go. Setup is simple, and everything from simple diffs up to three-way merge works reliably and swiftly.

Conclusions

• Git on Windows is full-featured, and works as advertised, and is not limited on Windows.

• Performance is generally very good, but comprehensive large blames might be slow.

• The TortoiseGit interface is seductive, but ultimately unsatisfying: you should try to learn git on the command-line. I have done both, and this route is more efficient.