msys, msys2 및 msysgit는 서로 어떻게 관련되어 있습니까?

msys, msys2 및 msysgit는 서로 어떻게 관련되어 있습니까?

---

주변을 검색했지만이 3 가지 버전의 MSYS로 진행중인 작업에 대한 자세한 설명을 찾을 수 없습니다. MSYS는 MinGW를 사용한 개발을 지원하기위한 최소한의 Linux 도구 포트라는 것을 이해합니다. 그러나 그 둘 사이의 관계에 대해서는 명확하지 않습니다. 개발 / 유지 관리 팀.

해결해야 할 특정 문제 :

• 어느 것이 활발하게 개발되고 있습니까? (특히 MSYS가 종료되었고 MSYS2가 활성화되어 있습니까?)
• 그들을 유지하는 그룹 사이의 관계는 무엇입니까? (특히 MSYS 팀이 MSYS2를 만들었습니까?)
• msysgit은 다른 것 중 하나만 사용합니까, 아니면 자체 MSYS 분기를 가지고 있습니까?
• 서로 호환되는 것이 있습니까?
• 특정 버전의 Windows와의 호환성 문제가 있습니까?
• 하나는 다른 것보다 주요 기능을 제공합니까?

---

면책 조항 : 저는 MSYS2 개발자입니다

MSYS는 죽지 않았지만 건강에 좋지 않다고 말할 수 있습니다. 몇 년 전 mingw 팀 이 Cygwin 을 따라 가지 않은 Cygwin의 포크 로 시작한 프로젝트 입니다.

msysgit은 약간의 커스텀 패치, bash와 perl의 구 버전, git의 기본 포트가 있는 약간 오래된 MSYS 버전의 포크입니다 .

MSYS2는 Mingw-builds 팀의 Alexey Pavlov (MinGW-w64 툴체인의 공식 패키지 관리자) 가 최근 Cygwin을 밀접하게 추적하는 최신 Cygwin 포크 로 시작한 프로젝트 입니다 . Alexey는 이전 MSYS 패치를 포팅하고 자신의 패치를 추가했습니다.

MSYS의 목표 인 네이티브 소프트웨어를 컴파일하는 데 필요한 Unix 도구를 제공 할뿐만 아니라 Pacman 패키지 관리자를 Arch Linux에서 이식했습니다. Pacman은 바이너리 꾸러미를 관리하는 것 이상의 의미를 지닙니다. makepkg라는 소프트웨어 빌드 인프라가있어 소프트웨어 빌드를위한 레시피 (PKGBUILD 및 패치 파일)를 작성할 수 있습니다. IMHO는 Pacman을 채택함으로써 Windows의 오픈 소스 개발을 위해 크게 변화했습니다. 모든 사람들이 자신의 맞춤형 쉘 스크립트를 해킹하는 대신 호환되지 않는 방식으로 소프트웨어를 빌드하는 대신 패키지는 이제 다른 패키지에 의존 할 수 있으며 PKGBUILD 파일을 사용하고 관련 패치를 새로운 PKGBUILD 구성을위한 참조로 사용할 수 있습니다. 그것'

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 ( )의 commit df5218b (2016 년 1 월 13 일)를 참조하십시오 . ^{( Junio ​​C Hamano 에 의해 병합 -- 커밋 116a866 , 2016 년 1 월 29 일)}dscho
gitster

오랜 시간 동안 Windows 용 Git은 Git의 2.x 릴리스보다 뒤떨어졌습니다. Windows 용 Git 개발자는 MSys에서 MSys2 로의 절실한 점프와 큰 점프가 일치하도록했기 때문입니다.

이것이 왜 그렇게 큰 문제인지 이해하려면 Git의 많은 부분이 이식 가능한 C로 작성되지 않았지만 Git은 POSIX 셸과 Perl을 사용하여 사용할 수 있습니다 .

스크립트를 지원하기 위해 Git for Windows는 Bash와 Perl이 포함 된 최소 POSIX 에뮬레이션 레이어를 제공해야하며 2007 년 8 월 Windows Git 노력이 시작되면 Cygwin의 제거 된 버전 인 MSys 를 사용하기로 결정했습니다 .
결과적으로 프로젝트의 원래 이름은 "msysGit"입니다. 슬프게도 Windows 사용자가 MSys에 대해 잘 알지 못하고 관리가 덜 되었기 때문에 많은 혼란을 초래했습니다 .

Windows 용 Git의 C 코드를 컴파일하기 위해 MSys도 사용되었습니다. GNU C 컴파일러의 두 가지 버전이 있습니다.

• POSIX 에뮬레이션 레이어에 암시 적으로 연결되는 것
• 그리고 평범한 Win32 API를 목표로하는 또 하나의 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 프로젝트는 최신 버전의 패키지를 빌드하여 상황을 해결하려고 시도했지만 특히 Git 개발과 관련이없는 신속한 조치가 필요한 Heartbleed 버그와 같은 문제로 상황을 빠르게 해결할 수 없었습니다. 더 Windows.

다행히도 MSys2 프로젝트 ( https://msys2.github.io/ )가 등장하여 Windows 2.x 용 Git의 기반으로 선택되었습니다.
MSys와 마찬가지로 MSys2도 Cygwin의 제거 된 버전이지만 Cygwin의 소스 코드를 통해 최신 상태로 유지됩니다 .
따라서 이미 내부적으로 유니 코드를 지원하며 Windows 용 Git 프로젝트가 시작된 이래로 64 비트 지원을 제공합니다.

MSys2는 또한 아치 리눅스에서 팩맨 패키지 관리 시스템을 포팅하여 많이 사용했다 . 이렇게하면 Linux 사용자가 yumor 에서 또는 apt-getMacOSX 사용자가 Homebrew 또는 MacPorts에서 또는 포트 시스템의 BSD 사용자에서 MSys2 로 사용하는 것과 동일한 편의성이 제공 됩니다. pacman -Syu설치된 모든 패키지를 최신 버전 으로 간단 하게 업데이트합니다. 현재 사용 가능.

MSys2도 매우 활발하며 일반적으로 일주일에 여러 번 패키지 업데이트를 제공합니다.

It still required a two-month effort to bring everything to a state where Git's test suite passes, many more months until the first official Git for Windows 2.x was released, and a couple of patches still await their submission to the respective upstream projects. Yet without MSys2, the modernization of Git for Windows would simply not have happened.

This commit lays the ground work to supporting MSys2-based Git builds.

---

In the comments, the question was asked in January 2016:

Since Git for Windows is already based on MSYS2, have the binaries that don't depend on the emulation layer been made available as an MSYS2 package?

Ray Donnelly answered at the time:

We haven't fully merged yet, no. We're working on it though.

But... madz points out that during early 2017, that effort did not pan out.
See:

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

The problem is that I cannot contribute changes that will result in a new msys2-runtime in a timely manner.
Not a big problem, though: I'll just keep the fork of Git for Windows running indefinitely.

The wiki therefore mentions now (2018):

Git for Windows created some patches for msys2-runtime that have not been sent upstream. (This had been planned, but it was determined in issue #284 that it would probably not be happening.)
This means that you have to install Git for Windows customized msys2-runtime to have a fully working git inside MSYS2.

---

Note that, since commit aeb582a9 (Git 2.22, Q2 2019), the Git for Windows project started the upgrade process to a MSYS2 runtime version based on Cygwin v3.x.

mingw: allow building with an MSYS2 runtime v3.x

Recently the Git for Windows project started the upgrade process to a MSYS2 runtime version based on Cygwin v3.x.

This has the very notable consequence that $(uname -r) no longer reports a version starting with "2", but a version with "3".

That breaks our build, as df5218b (config.mak.uname: support MSys2, 2016-01-13, Git v2.8.0-rc0) simply did not expect the version reported by uname -r to depend on the underlying Cygwin version: it expected the reported version to match the "2" in "MSYS2".

So let's invert that test case to test for anything else than a version starting with "1" (for MSys).
That should safeguard us for the future, even if Cygwin ends up releasing versions like 314.272.65536.

---

Git 2.22 (Q2 2019) will future-proof a test against an update to MSYS2 runtime v3.x series.

See commit c871fbe (07 May 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit b20b8fe, 19 May 2019)}

t6500(mingw): use the Windows PID of the shell

In Git for Windows, we use the MSYS2 Bash which inherits a non-standard PID model from Cygwin's POSIX emulation layer: every MSYS2 process has a regular Windows PID, and in addition it has an MSYS2 PID (which corresponds to a shadow process that emulates Unix-style signal handling).

With the upgrade to the MSYS2 runtime v3.x, this shadow process cannot be accessed via OpenProcess() any longer, and therefore t6500 thought incorrectly that the process referenced in gc.pid (which is not actually a real gc process in this context, but the current shell) no longer exists.

Let's fix this by making sure that the Windows PID is written into gc.pid in this test script so that git.exe is able to understand that that process does indeed still exist.

---

My understanding on the connections between them is

• cygwin offers POSIX emulation on top of windows
• msys tried to simplify cygwin but is obsolete from 2010
• msysGit - allowed git up to 1.9.4 in windwos (could be called git-for-windows-1.X), based on an old version of msys.
• msys2 - a simplified cygwin, forked from it, with changes from msys and kept in sync with features from cygwin, integrated with pacman
• minGW - initial minGW, abandoned from 2010
• minGW-w64 - a faster and better integration with windows, without POSIX
• git-for-windows-2.x - offers git from 2.X for windows using minGW-64, minGW-32 and when is not possible with a fallback to msys2

Fiddle with complete graph definition in mermaid

참고URL : https://stackoverflow.com/questions/25019057/how-are-msys-msys2-and-msysgit-related-to-each-other