msys、msys2、およびmsysgitはどのように互いに関連していますか？

私は周りを検索してきましたが、これら3つのバージョンのMSYSで何が起こっているのかについての完全な説明が見つかりません。（何を探すべきかわからない可能性は十分にあります。）MSYSはMinGWを使用した開発をサポートするLinuxツールの最小ポートであることを理解していますが、3つまたはそれらを開発/保守したチーム。

対処する特定の問題：

• 現在開発中のものはどれですか？（特に、MSYSは停止しており、MSYS2はアクティブですか？）
• それらを維持するグループ間の関係は何ですか？（特に、MSYSチームはMSYS2を作成しましたか？）
• msysgitは他の1つだけを使用しますか、それともMSYSの独自のブランチを持っていますか？
• これらのいずれかは互いに互換性がありますか？
• これらの特定のバージョンのWindowsとの互換性の問題はありますか？
• 一方が他方よりも主要な機能を提供していますか？

免責事項：私はMSYS2開発者です

MSYSは死んでいませんが、あまり健康的ではないようです。これは、Cygwinに追いついたことのないCygwinのフォークとして何年も前にMinGWチームによって開始されたプロジェクトです。

msysgitは、少し古いバージョンのMSYSのフォークであり、いくつかのカスタムパッチ、古いバージョンのBashとPerl、およびネイティブポートのGitが含まれています。

MSYS2はmingw-buildsチームのAlexey Pavlov（MinGW-w64ツールチェーンの公式パッケージャーです）がCygwinの最近のフォークとして開始したプロジェクトで、最新のCygwinを厳密に追跡して、古くならないようにします。Alexeyは、古いMSYSのパッチを移植し、独自のパッチをいくつか追加しました。

ネイティブソフトウェアをコンパイルするために必要なUnixツール（MSYSの目標）を提供するだけでなく、PacmanパッケージマネージャをArch Linuxから移植しました。パックマンは、バイナリパッケージの管理以上のものです（ただし、それは非常にうまく機能します）。makepkgと呼ばれるソフトウェア構築インフラストラクチャがあり、ソフトウェアを構築するためのレシピ（PKGBUILDおよびパッチファイル）を作成できます。

私見、パックマンの採用により、Windowsでのオープンソース開発の状況が大きく変わります。独自の特注シェルスクリプトをハッキングして、互換性のない方法でソフトウェアを構築する代わりに、パッケージを他のパッケージに依存させることができるようになり、PKGBUILDファイルと関連パッチを新しいPKGBUILDを構築するための参照として使用できます。（ネイティブの）Windowsが取得できる（特にArch Linux）のと同じくらいLinuxシステムに近く、インストールされているすべてのパッケージを簡単に更新できます。

Windows XP SP3を最低限の対象とし、32ビットと64ビットの両方のWindowsをサポートしています。MSYS2とmsysまたはmsysgitを混在させないでください。Pacmanはシステム全体を管理するために使用されるため、他のシステムのファイルは競合を引き起こします。

また、構築したプロジェクトにパッチをアップストリームし、他のオープンソースプロジェクトからの貢献を積極的に募っています。他のユーザーが私たちと一緒に作業するのが簡単であることを願っています。

メインのウェブサイトはSourceForgeにあり、PKGBUILDリポジトリへのリンクが含まれています。GitHubには、よりユーザーフレンドリーなインストーラーサイトもあります。

詳細については、IRC（oftc＃msys2）にご参加ください。

Git 2.8（2016年3月）には、2015年初頭にmsysgitを置き換えた新しいgit-for-windowsに対する msys2の重要性を説明する非常に詳細なコミットが含まれています。

Johannes Schindelin（）によるコミットdf5218b（2016年1月13日）を参照してくださいdscho。
^{（による合併Junio C浜野- gitster-で116a866コミット、2016年1月29日）を}

長い間、Git for Windowsの開発者は、GSys for Windows開発者がMSysからMSys2への十分に必要なジャンプと大きなジャンプを同時に実現したかったため、Gitの2.xリリースに遅れをとっていました。

これがこのような大きな問題である理由を理解するには、Gitの多くの部分がポータブルCで作成されていないことに注意してください。代わりに、GitはPOSIXシェルとPerlに依存して利用可能です。

スクリプトをサポートするために、Git for Windowsは、BashとPerlがスローされた最小限のPOSIXエミュレーションレイヤーを出荷する必要があります。必要があり、Git for Windowsの取り組みが2007年8月に始まったとき、この開発者は、CygwinのストリップバージョンであるMSysの使用に着手しました。
その結果、プロジェクトの元の名前は（悲しいことに、発生し、「msysGit」であった多くのいくつかのWindowsユーザーはのMSysについて知っている、とさえ少ない介護ので混乱を）。

Git for WindowsのCコードをコンパイルするために、MSysも使用されました。これは、GNU Cコンパイラの2つのバージョンを備えています。

• 暗黙的にPOSIXエミュレーション層にリンクするもの、
• もう1つはプレーンなWin32 APIをターゲットとしています（いくつかの便利な関数がスローされています）。

Git for Windowsの実行可能ファイルは後者を使用して構築されているため、実際には単なるWin32プログラムです。 POSIXエミュレーション層を必要とする実行可能ファイルとそうでない実行可能ファイルを区別するために、前者がMSys実行可能ファイルと呼ばれる場合、後者はMinGW（Windowsの最小GNU）と呼ばれます。

ただし、このMSysへの依存には課題もありました。

• WindowsのGitをより適切にサポートするために必要なMSysランタイムへの変更の一部は、上流で受け入れられなかったため、独自のフォークを維持する必要がありました。
• また、MSysランタイムは、UTF-8や64ビットなどをサポートするためにさらに開発されていません。パッケージ管理システムがないことは別として、かなり後（mingw-get導入されたとき）まで、MSys / MinGWプロジェクトによって提供される多くのパッケージはそれぞれに遅れていますソースコードのバージョン、特にBashとOpenSSL。

しばらくの間、Git for Windowsプロジェクトは、それらのパッケージの新しいバージョンをビルドしようとして状況を改善しようとしましたが、状況はすぐに受け入れられなくなりました。さらにウィンドウズ。

幸いなことに、その間にMSys2プロジェクト（https://msys2.github.io/）が登場し、Git for Windows 2.xのベースとして選択されました。
MSysと同じように、MSys2はCygwinの機能を削ったバージョンですが、Cygwinのソースコードでアクティブに最新の状態に保たれています。
これにより、内部ですでにUnicodeをサポートしており、Git for Windowsプロジェクトの開始以来、私たちが切望していた64ビットのサポートも提供しています。

MSys2はまた、Pacmanパッケージ管理システムをArch Linuxから移植し、多用しています。これは、Linuxユーザーがyumやapt-getに慣れていること、MacOSXユーザーがHomebrewやMacPortsに慣れていること、またはBSDユーザーがPortsシステムを使用していることと同じ便利さをMSys2にもたらしpacman -Syuます。現在利用可能。

MSys2も非常にアクティブで、通常、パッケージの更新を週に数回提供します。

すべてをGitのテストスイートが合格する状態にするまでに2か月の努力が必要でした。最初の公式のGit for Windows 2.xがリリースされるまでにさらに数か月かかり、いくつかのパッチはそれぞれの上流プロジェクトへの提出を待っています。 。しかし、MSys2がなければ、Git for Windowsの近代化は実現しなかったでしょう。

このコミットは、MSys2ベースのGitビルドをサポートするための土台を築きます。

コメントで、質問は2016年1月に行われました：

Git for WindowsはすでにMSYS2に基づいているので、エミュレーションレイヤーに依存しないバイナリがMSYS2パッケージとして利用可能になっていますか？

レイ・ドネリーは当時答えました：

まだ完全には統合していません。私たちはそれに取り組んでいます。

しかし... madz は、2017年の初めには、その努力はうまくいかなかったと指摘しています。
見る：

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

問題は、新しいmsys2-runtimeをタイムリーにもたらす変更を提供できないことです。
大きな問題ではありませんが、Git for Windowsのフォークを無期限に実行し続けます。

したがって、wikiは次のように述べています（2018）：

Git for Windowsは、上流に送信されていないmsys2-runtimeのパッチをいくつか作成しました。（これは計画されていましたが、問題＃284でおそらく発生しないと判断されました。）
これは、MSYS2内で完全に機能するgitを使用するには、Git for Windowsのカスタマイズされたmsys2-runtimeをインストールする必要があることを意味します。

以来、ことを注意コミットaeb582a9（Gitの2.22、Q2 2019）、Gitの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 "。

したがって、そのテストケースを反転させて、「1」で始まるバージョン（MSys用）以外のものをテストします。
Cygwinが314.272.65536のようなバージョンをリリースすることになっても、それは将来のために私たちを守るはずです。

Git 2.22（2019年第2四半期）は、MSYS2ランタイムv3.xシリーズへの更新に対するテストの将来性を保証します。

Johannes Schindelin（）によるcommit c871fbe（2019年5月7日）を参照してください。^{（による合併Junio C浜野- -にb20b8feコミット、2019年5月19日）を}dscho
gitster

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エミュレーションを提供します
• msysはCygwinを簡素化しようとしましたが、2010年から廃止されました
• msysGit-古いバージョンのmsysに基づいて、Windowsで最大1.9.4のGit（git-for-windows-1.Xと呼ばれることもあります）を許可しました。
• msys2 - msysからの変更を含み、Pacmanと統合されたCygwinの機能との同期が保たれた、簡略化されたCygwin。
• MinGW -2010年から廃止された最初のMinGW
• MinGW-w64 -POSIXを使用しない、Windowsとのより高速で優れた統合
• git-for-windows-2.x - MinGW-64、MinGW-32、およびmsys2へのフォールバックでは不可能な場合、2.XからWindows用のGitを提供します

いじる人魚で完全グラフの定義。