msys、msys2和msysgit之间有什么关联？

Question

我一直在搜索，但我找不到关于这3个版本的MSYS的全面描述。(完全有可能是我不知道该寻找什么。) 我确实理解MSYS是Linux工具的最小移植版，以支持使用MinGW进行开发，但我不清楚它们之间的关系或开发/维护它们的团队。

需要解决的特定问题：

• 哪些是正在积极开发中的？(特别是，MSYS已经死了，MSYS2还活着吗？)
• 维护它们的团队之间的关系是什么？(特别是，MSYS团队是否创建了MSYS2?)
• msysgit是只使用其中一个，还是有自己的MSYS分支?
• 它们中的任何一个是否相互兼容？
• 对于这些问题中的任意一个，是否存在与特定版本的Windows兼容性问题？
• 它们中的一个提供比另一个更重要的功能吗？

- jpmc26

---

在写这个问题之前，我认为（现在仍然如此），MSYS和MinGW是作为Cygwin的竞争对手而创建的，因为Cygwin（至少以前是这样；我不确定它的当前状态）强制任何新代码通过一个非常低效的兼容性层来调用Windows API，而不是直接调用Windows API。因此，我一直认为MSYS及其相关系统比Cygwin更轻量级，所以我对Cygwin的当前状态不感兴趣。如果你有兴趣的话，这可能会成为一个很好的后续问题，如果你能将它表述得合适的话，可以随意提问。 - jpmc26

我也曾有这样的印象，直到昨天我开始深入调查。正如@Ray Donnelly所指出的那样，你提到的所有三个版本的MSYS都是Cygwin的分支。因此从这个意义上讲，它们都属于"Cygwin"——这个问题实际上是关于Cygwin及其分支的。正如Ray所指出的，MSYS似乎注定要失败了。我自己检查了MSYS的代码；它已经过时，甚至缺乏对共享内存的基本同步。维护者们没有跟上上游的步伐，也没有得到上游Cygwin获得的共享内存修复。 - James Johnston

@JamesJohnston，我认为你误解了我的意思。我的观点是Cygwin没有（现在也没有？）支持在不使用兼容层的情况下构建新二进制文件。MSYS及其相关版本可以通过MinGW实现这一点。因此，尽管我非常清楚它们都源于Cygwin，但我对Cygwin不感兴趣。既然我对Cygwin不感兴趣，问这个问题就没有意义。此问题的重点还主要集中在分叉本身的历史、原因以及一些基本后果上。在试图选择不同版本的MSYS时，Cygwin的历史并不是真正相关的。 - jpmc26

我不明白的是为什么MSYS2开发人员和Cygwin开发人员不能达成一致，停止争吵，这样我们就可以停止这些愚蠢的分支了。Cygwin本来就受到很少关注，但至少有付费的Red Hat员工在为其工作；而这些分支甚至没有得到那样的支持。我在去年的Cygwin邮件列表中找到了有关让MSYS2成为Cygwin的钩子DLL的讨论，以便MSYS2不必分叉整个Cygwin DLL；显然这些讨论没有进展。虽然MSYS2现在很有活力，但我预见如果/当MSYS2志愿者停止更新它，它会像MSYS一样停滞不前。 - James Johnston

@JamesJohnston，我觉得你可能会在Ray在他的回答中提到的IRC频道上得到更好的答案。这个评论链变得太长并且偏离了主题。 - jpmc26

Answer 1

免责声明：我是MSYS2的开发人员。

虽然MSYS并没有死亡，但我认为它看起来也不是很健康。这是一个由MinGW团队多年前启动的项目，作为Cygwin的一个分支，但从未跟上Cygwin的步伐。

msysgit是较旧版本的MSYS的一个分支，带有一些自定义补丁、旧版的Bash和Perl以及Git的本地端口。

MSYS2是由mingw-builds团队（他们是MinGW-w64工具链的官方打包者）的Alexey Pavlov最近作为Cygwin的一个分支启动的项目，紧密跟踪最新的Cygwin，以避免过时。Alexey将旧的MSYS补丁向前移植，并添加了一些自己的补丁。

除了提供必要的Unix工具来编译本地软件——这是MSYS的声明目标之外，我们还从Arch Linux移植了Pacman包管理器。Pacman不仅仅是管理二进制包（尽管它做得很好），它还有一个软件构建基础设施，称为makepkg，允许创建用于构建软件的配方（PKGBUILD和补丁文件）。

在我看来，采用Pacman对Windows上的开源开发产生了重大影响。现在，每个人不再需要使用自己的定制shell脚本以混合、不兼容的方式构建软件，而是可以依赖其他软件包，并使用PKGBUILD文件和相关补丁作为构建新PKGBUILD的参考。这使得（本机）Windows系统更加接近Linux系统（特别是Arch Linux），并允许简单地更新所有已安装的软件包。

我们的最低要求是Windows XP SP3，并支持32位和64位Windows。请勿混用MSYS2与msys或msysgit。Pacman用于管理整个系统，因此来自其他系统的文件将会引起冲突。

我们还尝试向我们构建的项目上游贡献补丁，并积极征求其他开源项目的贡献。我们希望其他人发现与我们合作很容易。

我们的主要网站在SourceForge上，并包含指向我们PKGBUILD存储库的链接。我们还有一个更加用户友好的安装程序网站在GitHub上。

如果您需要更多信息，请随时加入我们的IRC（oftc #msys2）。

- Ray Donnelly

---

msys2可以用来构建和运行git（即取代msysgit）。 - eckes

MSYS2有一个git软件包，这是MSYS2版本而不是本地版本。要安装git：pacman -S git我们还在MINGW-packages存储库中拥有msysgit的进行中端口。 - Ray Donnelly

不，我们的MSYS2 Git已经实现了所有功能并且没有Hack。我们在其他软件包的开发中广泛使用它。有一个担忧，即由于MSYS2是Cygwin的分支，它会给文件操作带来很多额外负担，而Git需要大量的文件操作，因此本地Git速度会更快。证明或否认这一点的方法是同时运行两者并进行基准测试，这就是我们要做的。我应该小心使用术语，因为对于msysgit的提及涉及到两个不同的东西，即具有本地Windows git的msys-fork和本地Windows git。在这里，我指的是后者！ - Ray Donnelly

@eckes 我只想说，我已经使用MSYS2作为Git的工具几个月了。MSYS2也有一些不足之处（没有哪种软件是完美的），但我一直很满意。这些问题都与Git本身无关。 - jpmc26

msys2的承诺不负所望。加油，@RayDonnelly。 - bvj

Answer 2

Git 2.8 (2016年3月) 包含了一个非常详细的提交记录，解释了msys2对于新的git-for-windows的重要性，该版本在2015年初取代了msysgit。

请参见 提交记录df5218b (2016年1月13日)，作者是Johannes Schindelin (dscho)。
^{(由Junio C Hamano -- gitster --合并到提交记录116a866，2016年1月29日)}

长期以来，由于Git for Windows开发人员希望让这个大的跳跃与从MSys到MSys2的必要跳跃相一致，因此Git for Windows落后于Git 2.x版本。要理解为什么这是一个如此重要的问题，需要注意到Git的许多部分不是用便携式C语言编写的，而是依赖于POSIX shell和Perl可用性。为了支持脚本，Git for Windows必须使用Bash和Perl作为最小的POSIX仿真层进行交付，并且当Git for Windows开始于2007年8月时，该开发人员决定使用MSys，这是Cygwin的精简版本。因此，该项目的原始名称是“msysGit”（这导致了很多混乱，因为很少有Windows用户知道MSys，甚至更少的人关心）。为了编译Git for Windows的C代码，也使用了MSys：它支持GNU C编译器的两个版本：一个隐式链接到POSIX仿真层，另一个则针对纯Win32 API（加入了一些方便函数）。Git for Windows的可执行文件是使用后者构建的，因此它们实际上只是Win32程序。为了区分需要POSIX仿真层的可执行文件和不需要的可执行文件，将后者称为MinGW（Windows的极小GNU），将前者称为MSys可执行文件。这种依赖于MSys也带来了一些挑战：我们对MSys运行时的一些更改（支持Git for Windows更好）未被上游接受，因此我们不得不维护自己的分支。此外，MSys运行时也没有进一步开发以支持例如UTF-8或64位，而且除了缺乏软件包管理系统之外，许多由MSys / MinGW项目提供的软件包都落后于相应的源代码版本，特别是Bash和OpenSSL。有一段时间，Git for Windows项目试图通过尝试构建这些软件包的新版本来解决这种情况，但是情况很快变得难以承受，特别是像Heartbleed漏洞这样需要迅速采取行动而与进一步开发Git for Windows无关的问题。令人高兴的是，与此同时，MSys2项目出现了，并被选择为Git for Windows 2.x的基础。就像MSys一样，MSys2是Cygwin的精简版本，但它会与Cygwin的源代码保持最新状态。因此，它已经内部支持Unicode，并且它还提供了自Git for Windows项目开始以来我们渴望的64位支持。MSys2还从Arch Linux移植了Pacman软件包管理系统，并广泛使用它。这为Linux用户从yum或apt-get到MacOSX用户从Homebrew或MacPorts再到BSD用户从Ports系统所习惯的相同便利带来了MSys2：简单的pacman -Syu将更新所有已安装的软件包到当前可用的最新版本。MSys2也非常活跃，通常每周提供多次软件包更新。要使Git的测试套件通过，仍需要两个月的努力，直到发布第一个正式的Git for Windows 2.x还需要几个月，而一些补丁仍在等待提交给各自的上游项目。但是如果没有MSys2，Git for Windows的现代化就不会发生。此提交为支持基于MSys2的Git构建奠定了基础。

---

在评论中，问题是在2016年1月提出的：

由于Git for Windows已经基于MSYS2，那么不依赖仿真层的二进制文件是否已经作为MSYS2软件包提供？

Ray Donnelly当时回答道：

我们还没有完全合并。不过我们正在努力。

但是madz 指出在2017年初，这个努力没有得到实现。
请参见：

• Alexpux/MSYS2-packages PR 786（Pull Request 786）
• git-for-windows/git issue 284（问题284）

问题在于我无法及时贡献改变，以便产生新的msys2-runtime。
不过这不是大问题：我将一直保持Git for Windows的分支运行。

Wiki因此现在提到（2018年）：

Git for Windows为msys2-runtime创建了一些补丁，但尚未发送上游。（这已经计划过，但在问题＃284中确定可能不会发生。）
这意味着您必须安装Git for Windows定制的msys2-runtime才能在MSYS2内完全使用git。

---

请注意，自提交 aeb582a9（Git 2.22，2019年第二季度）以来，Git for Windows项目已开始升级过程，将基于Cygwin v3.x的MSYS2运行时版本应用到其中。

mingw：允许使用MSYS2运行时v3.x进行构建

最近，Git for Windows项目开始升级到基于Cygwin v3.x的MSYS2运行时版本。这具有非常显著的影响，即$(uname -r)不再报告以"2"开头的版本，而是以"3"开头的版本。这导致我们的构建出现问题，因为df5218b(config.mak.uname: support MSys2, 2016-01-13, Git v2.8.0-rc0)仅仅没有预料到uname -r所报告的版本依赖于底层的Cygwin版本：它期望报告的版本与"MSYS2"中的"2"匹配。因此，让我们将测试用例反转以测试任何不以"1"（对于MSys）开头的版本。即使Cygwin最终发布314.272.65536之类的版本，这也应该保护我们的未来。

---

Git 2.22 (Q2 2019)将针对MSYS2运行时v3.x系列的更新进行测试，以未来为导向。

请参见提交c871fbe（由Johannes Schindelin (dscho)于2019年5月7日发布）。
^{（由Junio C Hamano -- gitster --在提交b20b8fe中合并，于2019年5月19日）}

t6500(mingw): 使用shell的Windows PID

在Git for Windows中，我们使用MSYS2 Bash，该Bash继承了Cygwin的POSIX仿真层的非标准PID模型：每个MSYS2进程都有一个常规的Windows PID，此外还有一个MSYS2 PID（对应于模拟Unix样式信号处理的阴影进程）。

随着升级到MSYS2运行时v3.x，这个阴影进程不能再通过OpenProcess()访问，因此t6500错误地认为在gc.pid中引用的进程（在这种情况下不是真正的gc进程，而是当前的shell）不存在。

让我们通过确保将Windows PID写入此测试脚本中的gc.pid来修复这个问题，以便git.exe能够理解该进程确实仍然存在。

---

Git 2.37.3（2022年第三季度）演示了如何使用msys2，在Windows上有条件地允许构建Python解释器。

请查看由 Johannes Schindelin (dscho)于2022年7月29日提交的提交2f0623a, 提交7934c74, 提交49d279f。
^{(在2022年8月8日由Junio C Hamano -- gitster --在提交8dfa09f中合并)}

mingw: 移除不必要的 NO_CURL 指令

^{作者：Johannes Schindelin}

在df5218b（“config.mak.uname: support MSys2”，2016年1月13日，Git v2.8.0-rc0 - merge列在batch #4中），我们引入了支持在基于MSYS2的新版Git for Windows v2.x构建环境中构建Git的功能。

为此，我们将非msysGit部分（针对MSys1）分成两个部分，并且与MSys1共享NO_CURL = YesPlease设置不同的是，我们用空值覆盖了MSYS2中的该设置，因为我们非常希望使用libcurl构建Git for Windows。

但这是不必要的：我们以前从未设置过该变量，因此没有必要覆盖它。

让我们只需删除这个不必要的行。

- VonC

---

这引发了一个非常有趣的问题：既然Git for Windows已经基于MSYS2，那么不依赖仿真层的二进制文件是否已经作为MSYS2软件包提供？@RayDonnelly上面提到，MSYS2团队有兴趣创建这些类型的二进制文件，以查看它们所产生的性能差异。 - jpmc26

我们还没有完全合并，但我们正在努力。 - Ray Donnelly

进一步解释一下，目前为止，MSYS2的git软件包仍然链接到msys-2.0.dll，正在进行将MSYS2与Git for Windows合并的过程。一旦完成，我们预计将放弃我们的git软件包，改用Git for Windows提供的完全本地化的软件包，因为链接到msys-2.0.dll的软件包是为了支持构建本地化软件而存在的，并不是最终目标。 - Ray Donnelly

@RayDonnelly 现在的情况如何？如果用 MSYS2（包管理器）替换 Git for Windows，是否有任何缺点？ - Brecht Machiels

这里有一个后续问题：msys/git和git-for-windows/mingw-w64-x86_64-git之间有什么区别？ - Brecht Machiels

Answer 3

我对它们之间的联系的理解是：

• Cygwin 在 Windows 上提供 POSIX 模拟。
• msys 尝试简化 Cygwin, 但已于 2010 年被淘汰。
• msysGit - 在旧版 msys 基础上，允许在 Windows 上使用 Git 1.9.4（也可以称为 git-for-windows-1.X）。
• msys2 - 从 Cygwin 分支出来的简化版，融合了 msys 的改进，并与 Cygwin 的功能保持同步，同时集成了 Pacman。
• MinGW - 初始版本已于 2010 年停止维护。
• MinGW-w64 - 更快速、更好地与 Windows 集成，不支持 POSIX。
• git-for-windows-2.x - 使用 MinGW-64、MinGW-32，以及当不支持时的回退到 msys2，为 Windows 提供 Git 2.X。

操作

- raisercostin

---

漂亮的图形。+1。不过，“Git for Windows 1.0”确实是尽力而为完成的：https://dev59.com/IHI-5IYBdhLWcg3wu7FU#1704687（我在https://dev59.com/WWUo5IYBdhLWcg3wmQZN#50555740中提到）。 - VonC