How are msys, msys2, and msysgit related to each other?

Question

I've been searching around, but I can't find a thorough description of what's going on with these 3 versions of MSYS. (It's entirely possible I just don't know what to look for.) I do understand that MSYS is a minimal port of Linux tools to support development using MinGW, but I'm not clear on the relationship between the three of them or the teams that developed/maintain them.

Particular issues to address:

• Which ones are under active development? (In particular, is MSYS dead and MSYS2 active?)
• What is the relationship between the groups that maintain them? (In particular, did the MSYS team create MSYS2?)
• Does msysgit just use one of the others, or do they have their own branch of MSYS?
• Are any of these compatible with each other?
• Are there any compatibility issues with particular versions of Windows for any of these?
• Does one provide major features over the other?

Pulpboard

Specifically: MSYS was forked from Cygwin and never kept up with upstream. Why will MSYS2 succeed where MSYS failed? – Somme

@JamesJohnston Before writing this question, it was (and is) my understanding that MSYS and MinGW were created as a competitor to Cygwin because Cygwin (at least previously; I'm not sure of its current state) forced any new code to go through a rather non-performant compatibility layer instead of calling Windows APIs directly. As such, I've always seen MSYS and its relatives as a lighter weight system than Cygwin, so I wasn't interested in Cygwin's current status. That might make a good follow up question, if you're interested, though; feel free to ask it if you can phrase it to be on topic. – Pulpboard

I was under that impression as well until I started digging under the covers yesterday. All of the three versions of MSYS you mention are forks of Cygwin, as @Ray Donnelly points out. So in that sense, all of them are "Cygwin" - and this question is really about Cygwin and its forks. As Ray points out, it looks like MSYS is doomed. I examined the MSYS code myself; it is hopelessly obsolete and lacks even basic synchronization over shared memory. The maintainers just didn't keep up with upstream, and never got the fixes for shared memory that upstream Cygwin got. – Somme

@JamesJohnston I think you misunderstood. My point is that Cygwin doesn't (didn't?) support building new binaries without the compatibility layer. MSYS and relatives do, via MinGW. As such, I'm not interested in Cygwin, despite being well aware that all of them have roots in Cygwin. Since I'm not interested in Cygwin, it didn't make sense to ask about it. This question also focuses primarily on the history of the forking itself and the reasons for it and some rudimentary consequences of it. When trying to choose between different versions of MSYS, Cygwin's history isn't really relevant. – Pulpboard

I think that's wrong. I haven't tried it, but Cygwin offers a large number of MinGW packages, like mingw-gcc, mingw-binutils, mingw64-i686-gcc, mingw64-x86_64-gcc, etc. MSYS != MinGW. If you examine MSYS repository, you'll see it's just like Cygwin repository - same organization, code files, etc. Except, all the files are mostly from 10+ years ago... :( My understanding of MSYS is that it is just so that you can use GNU Make to transparently call out to Windows compilers that only understand Windows paths. – Somme

What I don't understand is why MSYS2 developers and Cygwin developers can't come to terms & quit squabbling so we can stop having these stupid forks. Cygwin gets little attention as it is, but at least there are paid Red Hat employee(s) working on it; the forks don't even get that. I found discussion from last year on the Cygwin mailing list about having MSYS2 just be a hook DLL for Cygwin so that MSYS2 didn't have to fork the entire Cygwin DLL; apparently those discussions didn't go far. While MSYS2 has energy now, I foresee it stagnating like MSYS if/when MSYS2 volunteers stop updating it – Somme

@JamesJohnston I think you might be able to get better answers to your questions on the IRC channel Ray mentions in his answer. This comment chain is getting rather long and straying off topic. – Pulpboard

Sorry @JamesJohnston, didn't notice the squabbling until your post. – Uncrowned

@JamesJohnston: hello from the future! MSYS2 is alive and kicking :) – Doiron

Answer 1

Disclaimer: I am an MSYS2 developer

While MSYS isn't dead, I would say it's not looking very healthy either. It is a project started by the MinGW team many years ago as a fork of Cygwin that never kept up with Cygwin.

msysgit is a fork of a slightly older version of MSYS with some custom patches, old versions of Bash and Perl and a native port of Git.

MSYS2 is a project started by Alexey Pavlov of the mingw-builds team (who are the official packagers for MinGW-w64 toolchains) as a recent fork of Cygwin which tracks the latest Cygwin closely so that it doesn't end up out of date. Alexey forward ported the old MSYS patches and added some of his own.

As well as providing the necessary Unix tools with which to compile native software - the stated goal of MSYS - we ported the Pacman package manager from Arch Linux. Pacman is more than just about managing binary packages (though it does that very well). It has a software building infrastructure called makepkg that allows the creation of recipes (PKGBUILD and patch files) for building software.

IMHO, the adoption of Pacman changes things significantly for open source development on Windows. Instead of everyone hacking on their own bespoke shell scripts to build software in a hodge-podge, incompatible way, packages can now depend on other packages and PKGBUILD files and associated patches can be used as a reference for constructing new PKGBUILDs. It's as close to a Linux system as a (native) Windows can get (Arch Linux in particular) and allows for simple updating of all the installed packages.

We target Windows XP SP3 as a minimum and support both 32-bit and 64-bit Windows. We would ask that you never mix MSYS2 with msys or msysgit. Pacman is used to manage the whole system and as such, files from the other systems will cause conflicts.

We also try to upstream our patches to the projects we build and actively solicit contributions from other open source projects. We hope others find it easy to work with us.

Our main website is on SourceForge, and it contains links to our PKGBUILD repositories. We also have a more user friendly installer site on GitHub.

Feel free to join us on IRC (oftc #msys2) if you want more information.

Comet

Can msys2 be used to build and run git (i.e. replace msysgit). – Margiemargin

MSYS2 has a git package. It is an MSYS2 version as opposed to a native version. To install git: pacman -S git .. we also have a work in progress port of msysgit in our MINGW-packages repository. – Comet

Thanks so much. That clears up a lot. You said that the MSYS2 team is working on a port of msysgit; why bother? Is there major functionality missing from the git package? – Pulpboard

No, our MSYS2 git is feature complete and hack-free. We use it extensively in the development of other packages. There is a concern that MSYS2 (as it's a fork of Cygwin) adds a good deal of overhead to file operations and because git is file-operation-heavy that a native git would be faster. The way to prove or disprove this is to have both and to benchmark them, so that's what we will do. I should be careful about the terms here as my references to msysgit are to two different things, the msys-fork with native Windows git and also native Windows git. Here I am referring to the latter! – Comet

it would be interesting if you might give some details on Cygwin/MSYS2 differences here: https://mcmap.net/q/21275/-differences-between-msys2-and-cygwin-closed – Stacee

@Margiemargin I just wanna say that I've been using MSYS2 for git for a few months now. MSYS2 has a couple rough areas (what software doesn't?), but I've been very happy using it. None of them were related to git itself. – Pulpboard

The promise of msys2 is living up to my expectations. Keep up the good work, @RayDonnelly – Uncrowned

Yep, MSYS2 is an incredible - or essential? - tool for those accustomed to developing in a POSIX/GNU workflow who still want to support Windows. It's basically what I always wished Cygwin could be ;-) But Cygwin is great in its own right! Thanks to all involved in originating and maintaining both. – Reifel

thanks for the clarification. basicly now we have msys2 and cygwin as up-to-date – Philippine

a little 2017' update/note from MSYS2 homepage: MSYS2 can't be installed on FAT* partitions. Current MSYS2 can't be installed on Windows XP anymore. - it's still the best MSYS* out there, though. – Ecumenicist

MSYS2 is life-changing. Hat's off to you sir. I started my foray into computers as a dirty and unwashed teenager in windows-land. In past years I have been enlightened with unix systems and tools. Now, these things all instantly became supported on windows thanks to this new implementation of an actually capable package manager. – Vitric

It isn't so much about being able to run various tools, that's always been the case one way or another, but it's really about being able to have the lightweight approach of mingw providing full performance, and supporting everything at a low enough level that it gets really interesting. I had never dreamed that this day would come so soon. – Vitric

Does the casing carry any information? MSys vs. MSYS, MSys2 vs. MSYS2. – Roller

Answer 2

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:

• Alexpux/MSYS2-packages PR 786
• git-for-windows/git issue 284

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.

---

Git 2.37.3 (Q3 2022) illustrates how msys2 is used, through conditionally allow building Python interpreter on Windows:

See commit 2f0623a, commit 7934c74, commit 49d279f (29 Jul 2022) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 8dfa09f, 08 Aug 2022)}

mingw: remove unneeded NO_CURL directive

^{Signed-off-by: Johannes Schindelin}

In df5218b ("config.mak.uname: support MSys2", 2016-01-13, Git v2.8.0-rc0 -- merge listed in batch #4), we introduced support for building Git for Windows in the then-brand new Git for Windows v2.x build environment that was based off of MSYS2.

To do that, we split the non-msysGit part (that targeted MSys1) in two, and instead of sharing the NO_CURL = YesPlease setting with MSys1, we overrode it for MSYS2 with the empty value because we very much want to build Git for Windows with libcurl.

But that was unnecessary: we never set that variable beforehand, therefore there is no need to override it.

Let's just remove that unnecessary line.

Castilian

This raises a very interesting question: 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? @RayDonnelly above mentions that the MSYS2 team had interest in creating those kinds of binaries to see what kind of performance difference it makes. – Pulpboard

We haven't fully merged yet, no. We're working on it though. – Comet

To expand on that .. Not yet, for now, MSYS2's git package still links to msys-2.0.dll, there is an ongoing process to merge MSYS2 with Git for Windows' and once this is completed we expect to just drop our git package for their fully native one since msys-2.0.dll-linked packages exist to support building native software and are not an end goal in their own right. – Comet

@RayDonnelly What is the status at this moment? If replace Git for Windows with MSYS2 (package management!), are there any disadvantages? – Wilburnwilburt

Here's a follow-up question: What are the differences between msys/git and git-for-windows/mingw-w64-x86_64-git? – Wilburnwilburt

@BrechtMachiels I was about to send you back to this answer ;) (and https://mcmap.net/q/21275/-differences-between-msys2-and-cygwin-closed/6309) – Castilian

2018 update - sounds like the process of merging the two was abandoned in 2017 as the developers couldn't reach agreement on change management strategy: github.com/Alexpux/MSYS2-packages/pull/… and github.com/git-for-windows/git/issues/284 – Gristly

@Gristly Thank you. I have included your comment for more visibility. – Castilian

Answer 3

My understanding on the connections between them is

• Cygwin offers POSIX emulation on top of windows
• msys tried to simplify Cygwin but is obsolete from 2010
• msysGit - allowed Git up to 1.9.4 on Windows (could be called git-for-windows-1.X), based on an old version of msys.
• msys2 - a simplified Cygwin, forked from it, with changes from msys and kept in sync with features from Cygwin, integrated with Pacman
• MinGW - initial MinGW, abandoned from 2010
• MinGW-w64 - a faster and better integration with windows, without POSIX
• git-for-windows-2.x - offers Git from 2.X for Windows using MinGW-64, MinGW-32 and when is not possible with a fallback to msys2

Fiddle with complete graph definition in mermaid.

Enmesh

Nice graphics. +1. The "Git for Windows 1.0" was really done on a best effort basis though: https://mcmap.net/q/12418/-why-kiln-is-based-on-mercurial-and-not-other-d-vcs (that I mention in https://mcmap.net/q/12419/-what-exactly-does-git-39-s-quot-rebase-preserve-merges-quot-do-and-why) – Castilian