-
Notifications
You must be signed in to change notification settings - Fork 21
Frequently Asked Questions
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 and incorporate changes from git.git.
The procedure can be outlined as follows:
git remote add junio https://github.com/git/git.git
git remote update junio origin
git fetch junio --tags
git checkout master
git pull origin master
git checkout -b tentative-foo
git branch -u origin/master
/share/msysgit/merging-rebase.sh foo # use --dry-run for testingHere foo is a tag from the junio remote.
Once all conflicts are resolved, commit the changes.
We then run the tests. To get a compact output it helps to use the prove framework. So configure this by editing the /git/config.mak file as follows:
DEFAULT_TEST_TARGET=prove
GIT_PROVE_OPTS=--timer --jobs 16
With this config in place, running make test runs the git tests under the prove test reporting aggregator. Once the tests complete, it will produce a simplified report of those tests that failed at the end. 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.
Git for Windows is the installer that most people should download to be able to use Git on Windows.
For historical reasons, the development of Git for Windows requires a development environment that resembles Unix more than Windows, and this development environment is called msysGit.
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 of a few very dedicated developers you might just as well be grateful for. If more people would have kept that in mind, and offered gratitude instead of whining, it is possible the principal developer behind that effort would still be interested to work on it.
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: complaining and trying to bully volunteers who do not need Subversion integration to fix your problem; that only will accomplish only two things: to make you look bad, and to make sure that our loss of interested developers is permanent.
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.
You will first have to build Perl from scratch because Subversion support in Git is implemented in Perl, using the Perl/Subversion bindings. Most likely you will actually have to upgrade Perl first, something that is not for the faint of heart and would impress the Git for Windows maintainers no end.
After that, you will have to adjust /src/subversion/release.sh to download, build and install a new Subversions version. Most likely it will be similar to Perl: it won't work out of the box, so you will have to adjust/add patches to /src/subversion/patches/. The release.sh script will have unpacked the Subversion sources into a subdirectory and initialized it as a new Git repository to facilitate working with/on the patches.
For technical reasons, Git for Windows cannot create files or directories when the absolute path is longer than 260 characters.
See this issue
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 underC:\dir2but will work underC:\dir1
or
- Run the command one directory below the symlink target. Instead of
C:\dir2, run it underC:\dir2\somedir
This issue has its own page. Quick summary: it is not huge. It just looks huge if you do not look closely.