We try to follow the git release schedule. When a core msysGit contributor reads that there is a new release, we try to update Git for Windows to the current 'next' branch of git.git.

We then run /share/msysGit/run-tests.sh (which is basically a slightly pimped up "make test" in /git/). Typically, there are one or two failures which we try to investigate, or send a message to the msysGit mailing list mentioning which tests need to be shown some love.

Once the person starting the process (we are very loose on procedures, basically the first person having time, the others realize from "git fetch"ing that the process was started) is reasonably happy with the test suite, he or she makes the packages (using /share/WinGit/release.sh, /share/WinGit/portable-release.sh, /share/msysGit/net/release.sh and /share/msysGit/full/release.sh) and uploads them to GoogleCode and sends a message to the msysGit and the Git mailing list.

MSys is an environment for Windows offering a Unix-type shell and a Perl interpreter. Because many parts of Git are still not builtins programmed in C, but instead shell and Perl scripts, Git for Windows needs such an environment.

Therefore we ship Git for Windows with a very minimal version of MSys.

MSys is also required to build Git, as we re-use the same Unix-type setup upstream Git uses. We ship a more complete MSys environment, including GCC, as build environment (which is therefore nick-named ''msysGit'').

We compile Git as a pure MinGW program, though, i.e. a program without any link-dependencies on anything but standard Windows libraries. So unless you need to use any parts of Git that are still implemented only as shell or Perl scripts, you can get away with running plain git.exe.

First of all, you're welcome. The fact that git-svn is supported on Windows at all is the result of multiple months of hard work (spent better than whining, BTW) of a few very dedicated developers you might just as well be grateful for.

Now to the technical reason why Subversion support was not upgraded in a long time: It is really tricky to build. git-svn is actually a Perl program, so it uses the Perl shipped with MSys (see this question for details). As git-svn is a Perl program, the Subversion binding used by git-svn is actually a Perl extension. It is not trivial to compile that extension on Windows (due to its lack of POSIX support and due to the lack of so many tools Unix developers take for granted), and so far nobody has successfully completed a Subversion upgrade.

So: what is the solution? Ideally, someone who needs it badly enough to tackle the upgrade of Subversion, contributing the work back to the msysGit project. This is Open Source, after all, therefore everybody is welcome to work on it. You could even offer money for somebody else to do it for you. One thing is almost certainly not going to work, however: whining and trying to bully volunteers who do not need Subversion integration to fix your problem; that only will accomplish only one thing: to make you look bad.

That is true. It is not particularly easy to upgrade it, either.

The reason is that we need to have an MSys version of Perl because we did not manage to compile the Subversion modules (which are written in C using POSIX features plain Windows does not offer, hence the need for MSys).

First of all, you need a development environment. Download and install the one-stop msysGit development environment installer. This will install the development environment and build an up-to-date Git version in it. You definitely want to install this development environment into a directory whose path does not have spaces in it. For example, C:\Program Files (x86)\msysGit is not a good place, while C:\msysGit is.

To be able to open the development environment quickly again, you might want to install a desktop icon using the method suggested in the default message of the command-line window which was kept open at the end of the installation procedure: /share/msysGit/add-shortcut.tcl desktop.

Second, you need to switch to the 'MSys' development environment. By default, msysGit is set up to compile MinGW programs, i.e. plain Windows programs that do not use any POSIX features. In contrast, the Perl-Subversion modules require POSIX features that are supported by the POSIX emulation layer MSys (see also What is this "MSys" thing in "MSysGit"?). To switch to the 'MSys' development environment, close all msysGit windows, install Git for Windows, start a Git Bash and switch to the msys branch: cd /c/msysGit/ && git fetch && git checkout -t origin/msys.

To build the current Perl, all you have to do is to call /src/perl/release.sh.

To upgrade Perl, that file -- /src/perl/release.sh -- has to be modified. Unfortunately, it is usually not enough to update the version number and MD5 checksum. Typically, the build will fail after doing that, which means that patches are needed. The patches required for the current Perl version are located in /src/perl/patches/ and will be applied automatically by the release.sh script.

The process is now to switch the directory to /src/perl/perl-<VERSION>/ (which is now a Git repository in its own right) and patch the sources until make passes. Then, those changes need to be committed and to be exported to /src/perl/patches/ using the command git format-patch -o /src/perl/patches/ -<NUMBER> where <NUMBER> is the number of commits on top of the initial one.

For technical reasons, Git for Windows cannot create files or directories when the absolute path is longer than 260 characters.

See e.g. this thread

See Git for Windows Unicode support documentation

Append your certificate (in pem format) to /bin/curl-ca-bundle.crt.

This error occurs when git clone/init commands are run inside a Windows symlink target directory root and it's because of the incompatibility between how Windows and Unix symlinks work. There are two workarounds to fix this:

• Run the command at the symlink source. For instance if you have a Windows symlink from C:\dir1 -> C:\dir2, the command will fail under C:\dir2 but will work under C:\dir1

or

• Run the command one directory below the symlink target. Instead of C:\dir2, run it under C:\dir2\somedir