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?
dubious wildcard support:
(problematic for .gitignore files)
send to the underlying OS-specific fnname() method: see this question and that one (or that one)
git-svn might not be very fast.
Source: this SO answer. It has made some good progress though.
the PATH need to be adjusted to prevent any conflict
Some commands are the same between Windows and the bash. (find, cp, rm, ...).
See this SO answer.
As cjrh comments, Git for Windows doesn't add its bin directory by default to the PATH.
some eol conversion can take place (Wnix vs. Windows eol)
See Definitive recommendation for git autocrlf settings.
The new and improved core.eol and eol attributes from Git1.7.2 are not there yet in msysgit.
(This is probably more of a comment than an answer, but my rep's not quite there yet.)
I wondered the same thing recently, and I wasn't able to dig up too much either. Here's one interesting discussion (discovered via a citation on Git's wikipedia entry).
As far as I can tell, the main issues are performance (particularly on Cygwin, and/or with large repositories) and file system issues (file name case-insensitivity, limited VFS).
Purely subjective/anecdotal:
I feel like Git is a much more pleasant experience running natively under Ubuntu 10.04 than on Cygwin under Win7 on the same machine--so much so that I've been shifting almost all of my freelance web development work to Ubuntu to take advantage of it (among other things). I learned Git on my OSX machine at work, so trying to work with it on Windows afterwards was almost painful. msysgit is definitely an improvement over Cygwin, but it still suffers from the limitations of the Windows file system.
EDIT: Apparently, msysgit chokes on filenames that were entered into git via a UTF8-aware filesystem, like Linux, which sucks.
I also just stumbled across GitSharp, a WIP native Windows implementation (discovered via this blog comment).
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.
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.
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.
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.
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.