msys，msys2和msysgit如何相互关联？

Question

我一直在寻找，但我无法找到这3个版本的MSYS的详细描述。 （完全有可能我只是不知道该寻找什么。）我明白MSYS是支持使用MinGW进行开发的Linux工具的最小端口，但我不清楚它们三者之间的关系还是开发/维护它们的团队。

要解决的特殊问题：

• 哪些正在积极开发中？ （特别是，MSYS死了，MSYS2有效吗？）
• 维护它们的群体之间有什么关系？ （特别是，MSYS团队是否创建了MSYS2？）
• msysgit只使用其中一个，还是有自己的MSYS分支？
• 这些中的任何一个是否相互兼容？
• 对于其中任何一种，特定版本的Windows是否存在任何兼容性问题？
• 是否提供了主要功能？

Answer 1

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

虽然MSYS没有死，但我会说它看起来也不健康。这是一个项目 许多年前由mingw团队开始作为 Cygwin的分支从未跟上Cygwin。

msysgit是稍微旧版本的MSYS的分支，带有一些自定义补丁，旧版本的bash和perl以及git的本机端口。

MSYS2是由mingw-builds团队的Alexey Pavlov（他们是MinGW-w64工具链的官方打包者）启动的项目，作为 Cygwin的最新分支，它紧密跟踪最新的Cygwin，以便它并没有过时。 Alexey转发了旧的MSYS补丁，并添加了一些自己的补丁。

除了提供用于编译本机软件的必要Unix工具 - MSYS的既定目标 - 我们从Arch Linux移植了Pacman包管理器。 Pacman不仅仅是管理二进制包（尽管它做得非常好）。它有一个名为makepkg的软件构建基础架构，允许创建用于构建软件的配方（PKGBUILD和补丁文件）。恕我直言，Pacman的采用改变了Windows上开源开发的重要性。而不是每个人都用他们自己的定制shell脚本来破解以不兼容的方式构建软件，现在包可以依赖于其他包，PKGBUILD文件和相关的补丁可以用作构建新PKGBUILD的参考。它与（本机）Windows可以获得（特别是Arch）一样接近Linux系统，并允许简单更新所有已安装的软件包。

我们将Windows XP SP3作为最低目标，并支持32位和64位Windows。我们要求你永远不要将MSYS2与msys或msysgit混合使用。 Pacman用于管理整个系统，因此来自其他系统的文件将导致冲突。

我们还尝试上传我们构建的项目的补丁，并积极征求其他开源项目的贡献。我们希望其他人能够轻松与我们合作。

我们的主网站位于Sourceforge，其中包含指向PKGBUILD存储库的链接。我们在github上有一个更友好的安装程序网站。

如果您想了解更多信息，请随时加入我们的IRC（oftc＃msys2）。

Answer 2

Git 2。8（2016年3月）包含一个非常详细的提交，解释了msys2对git-for-windows的新replaced msysgit in early 2015的重要性。

commit df5218b见Johannes Schindelin (dscho)（2016年1月13日） ^{（由Junio C Hamano -- gitster --合并于commit 116a866，2016年1月29日）}

  

很长一段时间，Git for Windows落后于Git的2.x版本，因为Git for Windows开发人员希望让这个大跳跃与从MSys到MSys2的急需跳跃重合。

     

要理解为什么这是一个如此大的问题，需要注意的是，Git的许多部分都不是用便携式C编写的，而是Git依赖于POSIX shell和Perl可用

     

为了支持脚本，Git for Windows必须提供一个最小的POSIX仿真层，其中包含Bash和Perl ，当Git for Windows工作于2007年8月启动时，此开发人员决定使用 MSys，一个精简的Cygwin版本   因此，该项目的原始名称是＆＃34; msysGit＆＃34; （遗憾的是，由于很少有Windows用户了解MSys，甚至更少关心，因此导致混淆很多。

     

为了编译Git for Windows的C代码，也使用了MSys：它运动   两个版本的GNU C编译器：

     

  
• 一个隐式链接到POSIX仿真层的文件，
  
• 和另一个以普通Win32 API为目标的（带有一些便利功能）。
  

     

Git for Windows＆＃39;可执行文件是使用后者构建的，因此它们实际上只是Win32程序。 要识别需要POSIX仿真层的可执行文件而不是那些，后者称为MinGW   （最小GNU for Windows），前者称为MSys可执行文件。

     

这种对MSys的依赖也带来了挑战：

     

  
• 我们对MSys运行时的一些更改 - 为了更好地支持Git for Windows所必需的 - 不被上游接受，所以我们必须维护自己的   叉子。
  
• 此外，MSys运行时未进一步开发以支持例如UTF-8或64位，除了缺少包管理系统，直到很久以后（引入mingw-get时），MSys / MinGW项目提供的许多包都落后于相应的源代码版本，特别是Bash和OpenSSL。
  

     

有一段时间，Git for Windows项目尝试通过尝试构建这些软件包的更新版本来解决这种情况，但情况很快变得难以理解，尤其是像Heartbleed bug这样的问题需要迅速采取与之无关的操作进一步开发Git for Windows。

     

令人高兴的是，与此同时，MSys2项目（https://msys2.github.io/）   出现了，并被选为Windows 2.x的Git的基础。
  就像MSys一样，MSys2是Cygwin的精简版，但确实如此   积极与Cygwin的源代码保持同步   因此，它已经在内部支持Unicode，并且它还提供了自Git for Windows项目开始以来我们渴望的64位支持。

     

MSys2还从Arch Linux移植了Pacman包管理系统   并大量使用。这给Linux带来了同样的便利   用户习惯于yum或apt-get以及MacOSX用户   曾经来自Homebrew或MacPorts，或来自Ports系统的BSD用户，   到MSys2：一个简单的pacman -Syu将更新所有已安装的软件包   目前可用的最新版本。

     

MSys2也非常活动，通常提供包更新   每周多次。

     

仍然需要两个月的努力才能把一切都带到一个州   Git的测试套件通过，比第一个官方要多几个月   Git for Windows 2.x发布了，还有几个补丁还在等待   他们提交给各自的上游项目。 但没有MSys2，   Git for Windows的现代化根本不会发生。

     

此提交为支持基于MSys2的Git构建奠定了基础。

In the comments，2016年1月提出了这个问题：

  

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

Ray Donnelly当时回答：

  

我们还没有完全合并，没有。我们正在研究它。

但是...... madz points out在2017年初，这项努力并没有成功 参见：

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

  

问题在于我无法及时提供会导致新的msys2-runtime的更改   但不是一个大问题：我只是让Git for Windows的分支无限期地运行。

The wiki因此现在提到（2018年）：

  

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

请注意，自commit aeb582a9（Git 2.22，2019年第2季度）以来，Git for Windows项目开始升级到基于Cygwin v3.x的MSYS2运行时版本。

  

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

     

最近，Git for Windows项目开始升级到基于Cygwin v3.x的MSYS2运行时版本。

     

这会产生$(uname -r)不再显着的显着后果   报告以＆＃34; 2＆＃34;开头的版本，但使用＆＃34; 3＆＃34;的版本。

     

这打破了我们的构建，df5218b（config.mak.uname：支持MSys2，   2016-01-13，Git v2.8.0-rc0）根本没想到uname -r报告的版本依赖于底层的Cygwin版本：它预计会报告   版本匹配＆＃34; 2＆＃34;在＆＃34; MSYS2＆＃34;。

     

因此，让我们将该测试用例转换为测试其他任何而不是以＆＃34; 1＆＃34;开头的版本。 （对于MSys）。
  这应该保护我们的未来，即使Cygwin最终发布314.272.65536等版本。

Git 2.22（2019年第二季度）将针对MSYS2运行时v3.x系列的更新进行面向未来的测试。

commit c871fbe见Johannes Schindelin (dscho)（2019年5月7日） ^{（由Junio C Hamano -- gitster --合并于commit b20b8fe，2019年5月19日）}

  

t6500(mingw)：使用shell的Windows PID

     

在Git for Windows中，我们使用继承非标准的MSYS2 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能够理解   该过程确实仍然存在。

Answer 3

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

• cygwin 在Windows顶部提供POSIX仿真
• msys 试图简化cygwin，但自2010年起已过时
• msysGit -基于旧版本的msys，在windwos中允许git最高为1.9.4（可以称为 git-for-windows-1.X ） 。
• msys2 -一个简化的cygwin，由它派生，具有msys的更改，并与cygwin的功能保持同步，与pacman集成
• minGW-初始minGW，从2010年起废弃
• minGW-w64 -与Windows更快更好地集成，无需POSIX
• git-for-windows-2.x -使用 minGW-64 ， minGW-32 从2.X为Windows提供git以及何时无法使用 msys2

摆弄complete graph definition in mermaid