msys、msys2、およびmsysgitはどのように相互に関連していますか？
私はあちこち検索してきましたが、これら3つのバージョンのMSYSで何が起こっているかについての詳細な説明を見つけることができません。 （何を探すべきかわからないだけです。）MSYSは、MinGWを使用した開発をサポートするLinuxツールの最小限のポートであることは理解していますが、これら3つの関係またはそれらを開発/維持するチーム。
対処すべき特定の問題：
- どれが活発に開発されていますか？ （特に、MSYSは死んでいて、MSYS2はアクティブですか？）
- それらを維持するグループ間の関係は何ですか？ （特に、MSYSチームはMSYS2を作成しましたか？）
- Msysgitは他の1つを使用するだけですか、それともMSYSの独自のブランチを持っていますか？
- これらは互いに互換性がありますか？
- これらのいずれかについて、Windowsの特定のバージョンとの互換性の問題はありますか？
- 一方が他方に対して主要な機能を提供しますか？
免責事項：私はMSYS2開発者です
MSYSが死んでいない間、私はそれも非常に健康に見えません。これは、何年も前にmingwチームによってCygwinのフォークとして開始されたプロジェクトであり、Cygwinに追いついたことはありません。
msysgitは、MSYSの少し古いバージョンのフォークですいくつかのカスタムパッチ、bashとPerlの古いバージョン、およびgitのネイティブポート。
MSYS2は、Mingw-buildsチーム（MinGW-w64ツールチェーンの公式パッケージャー）のAlexey PavlovによってCygwinの最近のフォークとして開始されたプロジェクトです最新のCygwinを密接に追跡します期限切れにならないように。 Alexeyは古いMSYSパッチを前方に移植し、彼自身のパッチをいくつか追加しました。
MSYSの目標であるネイティブソフトウェアをコンパイルするために必要なUnixツールを提供するとともに、Arch LinuxからPacmanパッケージマネージャーを移植しました。 Pacmanは、単にバイナリパッケージを管理するだけではありません（非常にうまく機能します）。 makepkgというソフトウェア構築インフラストラクチャがあり、ソフトウェアを構築するためのレシピ（PKGBUILDおよびパッチファイル）を作成できます。私見Pacmanの採用は、Windowsでのオープンソース開発の状況を大きく変えます。誰もが独自のシェルスクリプトをハッキングして互換性のない方法でソフトウェアを構築する代わりに、パッケージは他のパッケージに依存し、PKGBUILDファイルと関連するパッチを新しいPKGBUILDを構築するためのリファレンスとして使用できます。 （ネイティブ）Windowsが取得できる（特にArch）Linuxシステムに近いため、インストールされているすべてのパッケージを簡単に更新できます。
Windows XP SP3を少なくともターゲットとし、32ビットと64ビットの両方のWindowsをサポートします。 MSYS2とmsysまたはmsysgitを混在させないでください。 Pacmanはシステム全体の管理に使用されるため、他のシステムのファイルは競合を引き起こします。
また、ビルドするプロジェクトのパッチをアップストリーム化し、他のオープンソースプロジェクトからの貢献を積極的に募っています。私たちは、他の人たちが私たちと一緒に仕事をするのが簡単であることを願っています。
当社のメインWebサイトは Sourceforge にあり、PKGBUILDリポジトリへのリンクが含まれています。 github には、よりユーザーフレンドリーなインストーラーサイトもあります。
さらに情報が必要な場合は、IRC（oftc＃msys2）に参加してください。
Git 2.8（2016年3月）には、新しい git-for-windows which 2015年初頭にmsysgitに置き換えられた に対するmsys2の重要性を説明する非常に詳細なコミットが含まれています。
commit df5218b （2016年1月13日）by Johannes Schindelin（dscho） を参照してください。
（ 浜野潤夫-gitster- in commit 116a866 、2016年1月29日）
長い間、Git for WindowsはGitの2.xリリースに遅れをとっていました。これは、Git for Windowsの開発者が、MSysからMSys2への必要なジャンプとその大きなジャンプを一致させたいからです。
なぜこれが大きな問題なのかを理解するために、Gitの多くの部分は移植可能なCで書かれていないことに注意する必要がありますが、代わりにGitはPOSIXシェルとPerlに依存していることに注意してください 。
スクリプトをサポートするために、Git for Windowsは、BashとPerlがスローされた最小限のPOSIXエミュレーションレイヤーを出荷する必要があります。2007年8月にGit for Windowsの取り組みが始まったとき、この開発者はMSys、Cygwinの簡易バージョン。
その結果、プロジェクトの元の名前は "msysGit"でした（残念ながら、MSysを知っているWindowsユーザーはほとんどいないため、lot混乱を引き起こしました。お手入れ）。Git for WindowsのCコードをコンパイルするために、MSysも使用されました。MSysは、2つのバージョンのGNU Cコンパイラーを備えています。
- pOSIXエミュレーション層に暗黙的にリンクするもの、
- もう1つは、プレーンなWin32 APIを対象としています（いくつかの便利な関数がスローされています）。
Git for Windowsの実行可能ファイルは後者を使用して構築されているため、実際には単なるWin32プログラムです。 POSIXエミュレーション層を必要とする実行可能ファイルとそうでないものを区別するため、前者がMSys実行可能ファイルと呼ばれる場合、後者はMinGW（Windowsでは最小GNU）と呼ばれます。
ただし、MSysへのこの依存には課題もありました。
- mSysランタイムへの変更の一部（Git for Windowsをより適切にサポートするために必要）は上流で受け入れられなかったため、独自のフォークを維持する必要がありました。
- また、MSysランタイムは、たとえばUTF-8または64ビット、および後で（
mingw-getが導入されたときまで）パッケージ管理システムがなかったことを除けば、MSys/MinGWプロジェクトによって提供された多くのパッケージは、それぞれのソースコードバージョン、特にBashおよびOpenSSL。しばらくの間、Git for Windowsプロジェクトは、これらのパッケージの新しいバージョンを作成しようとすることで状況を改善しようとしましたが、特にSwiftアクションを必要としないHeartbleedバグのような問題で、状況はすぐに受け入れられなくなりましたGit for Windowsの開発をさらに進めます。
幸いなことに、MSys2プロジェクト（ https://msys2.github.io/ ）が登場し、Git for Windows 2.xのベースとして選ばれました。
MSysと同じように、MSys2はCygwinの簡易バージョンですが、Cygwinのソースコードで積極的に最新の状態に保たれています。
これにより、既にユニコードを内部でサポートしており、Git for Windowsプロジェクトの開始以来切望していた64ビットのサポートも提供します。MSys2は、Arch LinuxからPacmanパッケージ管理システムも移植し、頻繁に使用しています。これにより、Linuxユーザーは
yumまたはapt-getから、MacOSXユーザーはHomebrewまたはMacPorts、またはPortsシステムのBSDユーザーからMSys2に慣れているのと同じ利便性が得られます：単純なpacman -Syuは、インストールされているすべてのパッケージを現在利用可能な最新バージョンに更新します。MSys2もveryアクティブで、通常はパッケージの更新を週に複数回提供します。
最初の公式Git for Windows 2.xがリリースされるまで、Gitのテストスイートが合格する状態にするためにすべてを2か月の努力が必要でした。さらに、それぞれのアップストリームプロジェクトへのパッチの提出を待っています。 まだMSys2がなければ、Git for Windowsの近代化はまったく起こりませんでした。
このコミットにより、MSys2ベースのGitビルドをサポートするための基礎作業が行われます。
コメントで 、2016年1月に質問されました：
Git for WindowsはすでにMSYS2に基づいているため、エミュレーションレイヤーに依存しないバイナリがMSYS2パッケージとして利用可能になりましたか？
レイ・ドネリー 当時の回答：
まだ完全には統合されていません。しかし、私たちはそれに取り組んでいます。
しかし... madzpoints out 2017年初頭、その努力はうまくいきませんでした。
見る：
問題は、新しいmsys2-runtimeをタイムリーにもたらす変更を提供できないことです。
大きな問題ではありませんが、Git for Windowsのフォークを無期限に実行し続けるだけです。
ウィキ したがって、今言及している（2018）：
Git for Windowsは、アップストリームに送信されていないmsys2-runtimeのパッチをいくつか作成しました。 （これは計画されていましたが、問題＃284でおそらく発生しないと判断されました。）
これは、Git for Windowsをカスタマイズしてmsys2-runtimeをインストールし、MSYS2内でgitを完全に機能させる必要があることを意味します。
commit aeb582a9 （Git 2.22、Q2 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：MSys2をサポート、2016-01-13、Git v2.8.0-rc0）は、単にuname -rによって報告されるバージョンを期待していなかったため、ビルドを中断します基礎となるCygwinのバージョンに依存するため：報告されたバージョンが「MSYS2」の「2」と一致することを期待していました。したがって、そのテストケースを反転して、「=」で始まるバージョン（MSysの場合）以外のその他をテストします。
Cygwinが314.272.65536のようなバージョンをリリースしたとしても、それは将来のために私たちを守るはずです。
Git 2.22（2019年第2四半期）は、MSYS2ランタイムv3.xシリーズのアップデートに対するテストの将来性を保証します。
commit c871fbe （2019年5月7日）by Johannes Schindelin（dscho） を参照してください。
（ C浜野順夫-gitster- in commit b20b8fe 、2019年5月19日）
t6500(mingw)：シェルのWindows PIDを使用しますGit for Windowsでは、CygwinのPOSIXエミュレーションレイヤーから非標準のPIDモデルを継承するMSYS2 Bashを使用します。すべてのMSYS2プロセスには通常のWindows PIDがあり、さらにMSYS2 PID（エミュレートするシャドウプロセスに対応します） Unixスタイルのシグナル処理）。
MSYS2ランタイムv3.xへのアップグレードにより、このシャドウプロセスは
OpenProcess()を介してアクセスできなくなり、t6500はgc.pidで参照されているプロセス（実際にはgcプロセスではない）と誤って考えましたこのコンテキストでは、現在のシェル）はもう存在しません。このテストスクリプトの
gc.pidにWindows PIDが書き込まれていることを確認して、これを修正し、git.exeがそのプロセスが実際に存在することを理解できるようにします。
それらの間の接続に関する私の理解は
- cygwinは、ウィンドウの上部でPOSIXエミュレーションを提供します
- msyscygwinを単純化しようとしましたが、2010年から廃止されました
- msysGit-windwosで最大9.4のgitを許可（git-for-windows-1と呼ぶことができます） X）、msysの古いバージョンに基づきます。
- msys2-簡略化されたcygwin、そこから分岐、msysからの変更、cygwinの機能との同期、pacmanとの統合
- minGW -2010年から放棄された最初のminGW
- minGW-w64-POSIXを使用しない、Windowsとのより高速でより良い統合
- git-for-windows-2.x-minGW-64、minGW-32、およびmsys2
人魚の完全なグラフ定義 をいじる