Как связаны между собой msys, msys2 и msysgit?

Ответ 1

Отказ от ответственности: я разработчик MSYS2

Пока MSYS не мертв, я бы сказал, что он не выглядит очень здоровым. Это проект начатый многолетней командой mingw как вилка Cygwin, которая никогда не поддерживала Cygwin.

msysgit - это вилка немного более старой версии MSYS с некоторыми пользовательскими патчами, старыми версиями bash и perl и собственным портом git.

MSYS2 - проект, начатый Алексеем Павловым из команды mingw-builds (которые являются официальными упаковщиками для инструментальных средств MinGW-w64) как недавняя вилка Cygwin, которая отслеживает последний Cygwin, так что он не заканчивается устаревшим. Алексей вперед портировал старые патчи MSYS и добавил некоторые из своих.

Помимо предоставления необходимых инструментов Unix для компиляции собственного программного обеспечения - заявленной цели MSYS - мы портировали менеджер пакетов Pacman из Arch Linux. Pacman - это больше, чем просто управление бинарными пакетами (хотя он делает это очень хорошо). Он имеет инфраструктуру создания программного обеспечения под названием makepkg, которая позволяет создавать рецепты (PKGBUILD и файлы патчей) для создания программного обеспечения. IMHO принятие Pacman существенно изменило ситуацию для разработки Open Source в Windows. Вместо того, чтобы каждый взломать собственные скрипты оболочки для создания программного обеспечения в hodge-podge, несовместимый способ, пакеты теперь могут зависеть от других пакетов, а файлы PKGBUILD и связанные с ними патчи могут использоваться в качестве ссылки для построения новых PKGBUILD. Он как можно ближе к системе Linux как (родной) Windows может получить (в частности, Arch) и позволяет просто обновлять все установленные пакеты.

Мы ориентируемся на Windows XP SP3 как минимум и поддерживаем 32-битную и 64-битную Windows. Мы просим вас не смешивать MSYS2 с msys или msysgit. Pacman используется для управления всей системой, и поэтому файлы из других систем будут вызывать конфликты.

Мы также пытаемся воссоздать наши патчи для проектов, которые мы строим, и активно запрашивать вклады от других проектов с открытым исходным кодом. Мы надеемся, что другим нам будет легко работать с нами.

Наш главный сайт находится на Sourceforge и содержит ссылки на наши репозитории PKGBUILD. У нас также есть более удобный сайт-установщик на github.

Не стесняйтесь присоединяться к нам в IRC (oftС# msys2), если вам нужна дополнительная информация.

Ответ 2

Git 2.8 (март 2016 года) включает в себя очень подробный коммит, который объясняет важность msys2 для нового git-for-windows, который заменил msysgit в начале 2015 года.

См. Коммит df5218b (13 января 2016 г.) Йоханнеса dscho (dscho).
^{(Объединено Junio C Hamano - gitster - в коммите 116a866, 29 января 2016 г.)}

Долгое время Git для Windows отставал от выпусков Git 2.x, потому что разработчики Git для Windows хотели, чтобы этот большой скачок совпал с столь необходимым переходом от MSys к MSys2.

Чтобы понять, почему это такая большая проблема, необходимо отметить, что многие части Git написаны не на переносимом C, а вместо этого Git полагается на оболочку POSIX и Perl, которые будут доступны.

Для поддержки сценариев Git для Windows должен поставлять минимальный слой эмуляции POSIX с добавлением Bash и Perl, а когда в августе 2007 года началась работа над Git для Windows, этот разработчик решил использовать MSys, урезанную версию Cygwin.
Следовательно, первоначальное название проекта было "msysGit" (что, к сожалению, вызвало много путаницы, потому что мало кто из Windows знает о MSys, и даже меньше заботится).

Для компиляции кода C для Git для Windows также использовался MSys: он поддерживает две версии компилятора GNU C:

• тот, который неявно связан с уровнем эмуляции POSIX,
• и другой, предназначенный для простого Win32 API (с несколькими добавленными вспомогательными функциями).

Исполняемые файлы Git для Windows создаются с использованием последних, и поэтому они на самом деле являются программами Win32. Чтобы отличить исполняемые файлы, требующие уровня эмуляции POSIX, от тех, которые этого не делают, последние называются MinGW (Minimal GNU для Windows), тогда как первые называются исполняемыми файлами MSys.

Эта зависимость от MSys также вызывала проблемы:

• некоторые из наших изменений в среде выполнения MSys, необходимые для лучшей поддержки Git для Windows, не были приняты в апстрим, поэтому нам пришлось поддерживать собственный форк.
• Кроме того, среда выполнения MSys не получила дальнейшего развития для поддержки, например, UTF-8 или 64-битной, и, кроме того, что не имела системы управления пакетами намного позже (когда была введена mingw-get), многие пакеты, предоставляемые проектом, отставали от MSys/MinGW. за соответствующими версиями исходного кода, в частности Bash и OpenSSL.

Некоторое время проект Git для Windows пытался исправить ситуацию, пытаясь создать более новые версии этих пакетов, но ситуация быстро стала несостоятельной, особенно с такими проблемами, как ошибка Heartbleed, требующая быстрых действий, которые не имеют ничего общего с разработкой Git для Окна дальше.

К счастью, тем временем появился проект MSys2 (https://msys2.github.io/), который был выбран в качестве основы для Git для Windows 2.x.
Как и MSys, MSys2 является урезанной версией Cygwin, но она активно обновляется с исходным кодом Cygwin.
Таким образом, он уже поддерживает Unicode внутри, а также предлагает 64-битную поддержку, к которой мы стремились с начала проекта Git для Windows.

MSys2 также перенес систему управления пакетами Pacman из Arch Linux и активно использует ее. Это приносит то же удобство, к которому привыкли пользователи Linux из yum или apt-get, и к которому привыкли пользователи MacOSX из Homebrew или MacPorts или пользователей BSD из системы портов, в MSys2: простой pacman -Syu будет обновить все установленные пакеты до новейших доступных на данный момент версий.

MSys2 также очень активен, обычно предоставляет обновления пакетов несколько раз в неделю.

Потребовалось еще два месяца, чтобы привести все в состояние, в котором проходит тестовый набор Git, еще много месяцев, пока не был выпущен первый официальный Git для Windows 2.x, и пара патчей все еще ожидает их отправки в соответствующие апстрим-проекты., Однако без MSys2 модернизация Git для Windows просто не состоялась бы.

Этот коммит закладывает основу для поддержки сборок Git на основе MSys2.

В комментариях вопрос был задан в январе 2016 года:

Поскольку Git для Windows уже основан на MSYS2, были ли двоичные файлы, не зависящие от уровня эмуляции, доступны в виде пакета MSYS2?

Рэй Доннелли ответил тогда:

Мы еще не полностью слились, нет. Мы работаем над этим, хотя.

Но... Мадз отмечает, что в начале 2017 года эти усилия не увенчались успехом.
Увидеть:

• Alexpux/MSYS2-packages PR 786
• git-for-windows/git выпуск 284

Проблема в том, что я не могу своевременно вносить изменения, которые приведут к новому времени msys2 -r.
Не большая проблема, хотя: я просто буду держать форк Git для Windows на неопределенное время.

Поэтому вики упоминает сейчас (2018):

Git для Windows создал несколько патчей для msys2 -r untime, которые не были отправлены в апстрим. (Это было запланировано, но в выпуске № 284 было определено, что этого, вероятно, не произойдет.)
Это означает, что вы должны установить Git для Windows, настроенную на msys2 -r, чтобы иметь полностью рабочий git внутри MSYS2.

Обратите внимание, что после фиксации aeb582a9 (Git 2.22, Q2 2019) проект Git для Windows запустил процесс обновления до версии MSYS2, основанной на Cygwin v3.x.

mingw: разрешить сборку с MSYS2 runtime v3.x

Недавно проект Git для Windows начал процесс обновления до версии MSYS2, основанной на Cygwin v3.x.

Это имеет очень заметное следствие, что $(uname -r) больше не сообщает о версии, начинающейся с "2", а о версии с "3".

Это нарушает нашу сборку, так как df5218b (config.mak.uname: support MSys2, 2016-01-13, Git v2.8.0 -r c0) просто не ожидал, что версия, сообщаемая uname -r будет зависеть от базового Cygwin версия: ожидается, что заявленная версия будет соответствовать "2" в "MSYS2".

Итак, давайте инвертируем этот тест для проверки чего-либо, кроме версии, начинающейся с "1" (для MSys).
Это должно защитить нас на будущее, даже если Cygwin в конечном итоге выпустит такие версии, как 314.272.65536.

Git 2.22 (Q2 2019) станет тестом на будущее против обновления серии MSYS2 runtime v3.x.

См. Коммит c871fbe (07 мая 2019 г.) Йоханнеса dscho (dscho).
^{(Объединено Junio C Hamano - gitster - в коммите b20b8fe, 19 мая 2019 г.)}

t6500(mingw): использовать Windows PID оболочки

В Git для Windows мы используем MSYS2 Bash, который наследует нестандартную модель PID от уровня эмуляции Cygwin POSIX: каждый процесс MSYS2 имеет обычный PID Windows, а также PID MSYS2 (который соответствует теневому процессу, который эмулирует Обработка сигналов в стиле Unix).

При обновлении до среды выполнения MSYS2 v3.x этот теневой процесс больше не может быть доступен через OpenProcess(), и поэтому t6500 неправильно подумал, что процесс, на который ссылается gc.pid (который на самом деле не является реальным процессом gc в этом контексте, но текущая оболочка) больше не существует.

Давайте исправим это, убедившись, что PID Windows записан в gc.pid в этом тестовом сценарии, чтобы git.exe мог понять, что этот процесс действительно все еще существует.

Ответ 3

Мое понимание связей между ними

• cygwin предлагает эмуляцию POSIX поверх окон
• msys пытался упростить Cygwin, но устарел с 2010 года
• msysGit - разрешено использовать git до 1.9.4 в windwos (можно назвать git-for-windows-1.X), основываясь на старой версии msys.
• msys2 - упрощенный cygwin, разветвленный из него, с изменениями из msys и синхронизированный с функциями cygwin, интегрированный с pacman
• minGW - начальная minGW, заброшенная с 2010 года
• minGW-w64 - более быстрая и лучшая интеграция с Windows, без POSIX
• git-for-windows-2.x - предлагает git из 2.X для окон, использующих minGW-64, minGW-32 и, когда это невозможно, с отступлением до msys2

Скрипка с полным определением графа в русалке