Git 2.8 (March 2016) includes a very detailed commit which explains the importance of msys2 for the new git-for-windows which replaced msysgit in early 2015.
See commit df5218b (13 Jan 2016) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 116a866, 29 Jan 2016)
For a long time, Git for Windows lagged behind Git's 2.x releases because the Git for Windows developers wanted to let that big jump coincide with a well-needed jump away from MSys to MSys2.
To understand why this is such a big issue, it needs to be noted that many parts of Git are not written in portable C, but instead Git relies on a POSIX shell and Perl to be available.
To support the scripts, Git for Windows has to ship a minimal POSIX emulation layer with Bash and Perl thrown in, and when the Git for Windows effort started in August 2007, this developer settled on using MSys, a stripped down version of Cygwin.
Consequently, the original name of the project was "msysGit" (which, sadly, caused a lot of confusion because few Windows users know about MSys, and even less care).
To compile the C code of Git for Windows, MSys was used, too: it sports
two versions of the GNU C Compiler:
- one that links implicitly to the POSIX emulation layer,
- and another one that targets the plain Win32 API (with a few convenience functions thrown in).
Git for Windows' executables are built using the latter, and therefore they are really just Win32 programs. To discern executables requiring the POSIX emulation layer from the ones that do not, the latter are called MinGW
(Minimal GNU for Windows) when the former are called MSys executables.
This reliance on MSys incurred challenges, too, though:
- some of our changes to the MSys runtime -- necessary to support Git for Windows better -- were not accepted upstream, so we had to maintain our own
fork.
- Also, the MSys runtime was not developed further to support e.g. UTF-8 or 64-bit, and apart from lacking a package management system until much later (when
mingw-get was introduced), many packages provided by the MSys/MinGW project lag behind the respective source code versions, in particular Bash and OpenSSL.
For a while, the Git for Windows project tried to remedy the situation by trying to build newer versions of those packages, but the situation quickly became untenable, especially with problems like the Heartbleed bug requiring swift action that has nothing to do with developing Git for Windows further.
Happily, in the meantime the MSys2 project (https://msys2.github.io/)
emerged, and was chosen to be the base of the Git for Windows 2.x.
Just like MSys, MSys2 is a stripped down version of Cygwin, but it is
actively kept up-to-date with Cygwin's source code.
Thereby, it already supports Unicode internally, and it also offers the 64-bit support that we yearned for since the beginning of the Git for Windows project.
MSys2 also ported the Pacman package management system from Arch Linux
and uses it heavily. This brings the same convenience to which Linux
users are used to from yum or apt-get, and to which MacOSX users are
used to from Homebrew or MacPorts, or BSD users from the Ports system,
to MSys2: a simple pacman -Syu will update all installed packages to
the newest versions currently available.
MSys2 is also very active, typically providing package updates
multiple times per week.
It still required a two-month effort to bring everything to a state
where Git's test suite passes, many more months until the first official
Git for Windows 2.x was released, and a couple of patches still await
their submission to the respective upstream projects. Yet without MSys2,
the modernization of Git for Windows would simply not have happened.
This commit lays the ground work to supporting MSys2-based Git builds.
In the comments, the question was asked in January 2016:
Since Git for Windows is already based on MSYS2, have the binaries that don't depend on the emulation layer been made available as an MSYS2 package?
Ray Donnelly answered at the time:
We haven't fully merged yet, no. We're working on it though.
But... madz points out that during early 2017, that effort did not pan out.
See:
The problem is that I cannot contribute changes that will result in a new msys2-runtime in a timely manner.
Not a big problem, though: I'll just keep the fork of Git for Windows running indefinitely.
The wiki therefore mentions now (2018):
Git for Windows created some patches for msys2-runtime that have not been sent upstream. (This had been planned, but it was determined in issue #284 that it would probably not be happening.)
This means that you have to install Git for Windows customized msys2-runtime to have a fully working git inside MSYS2.
Note that, since commit aeb582a9 (Git 2.22, Q2 2019), the Git for Windows project started the upgrade process to a MSYS2 runtime version based on Cygwin v3.x.
mingw: allow building with an MSYS2 runtime v3.x
Recently the Git for Windows project started the upgrade process to a MSYS2 runtime version based on Cygwin v3.x.
This has the very notable consequence that $(uname -r) no longer
reports a version starting with "2", but a version with "3".
That breaks our build, as df5218b (config.mak.uname: support MSys2,
2016-01-13, Git v2.8.0-rc0) simply did not expect the version reported by uname -r to depend on the underlying Cygwin version: it expected the reported
version to match the "2" in "MSYS2".
So let's invert that test case to test for anything else than a version starting with "1" (for MSys).
That should safeguard us for the future, even if Cygwin ends up releasing versions like 314.272.65536.
Git 2.22 (Q2 2019) will future-proof a test against an update to MSYS2 runtime v3.x series.
See commit c871fbe (07 May 2019) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit b20b8fe, 19 May 2019)
t6500(mingw): use the Windows PID of the shell
In Git for Windows, we use the MSYS2 Bash which inherits a non-standard
PID model from Cygwin's POSIX emulation layer: every MSYS2 process has a
regular Windows PID, and in addition it has an MSYS2 PID (which
corresponds to a shadow process that emulates Unix-style signal
handling).
With the upgrade to the MSYS2 runtime v3.x, this shadow process cannot
be accessed via OpenProcess() any longer, and therefore t6500 thought
incorrectly that the process referenced in gc.pid (which is not
actually a real gc process in this context, but the current shell) no
longer exists.
Let's fix this by making sure that the Windows PID is written into
gc.pid in this test script so that git.exe is able to understand
that that process does indeed still exist.
