Replies: 4 comments 6 replies
-
Interested, but I lack sufficient knowledge to do anything beneficial or fundamental. |
Beta Was this translation helpful? Give feedback.
-
Thanks @dscho. We had a small meetup just now and talked about working through your list. Some small notes that came out of it (just from me and @elieux):
|
Beta Was this translation helpful? Give feedback.
-
Is it possible not to change that behavior please? 🥺 I prefer config files to be store in |
Beta Was this translation helpful? Give feedback.
-
I've started with something easy: msys2/msys2-runtime#143 How do we want to keep track of the list above? Can I edit the original post, check those boxes and add links to PRs? |
Beta Was this translation helpful? Give feedback.
-
The main obstacle when I migrated Git for Windows from MSys to MSYS2 was that the MSYS2 runtime is opinionated in a way that disagrees with Git's expectations (as documented in its test suite).
That is the reason why Git for Windows ships with a fork of the MSYS2 runtime, and that in turn is the obstacle why the Git for Windows cannot trivially maintain a
mingw-w64-git
definition inmsys2/MINGW-packages
: it would not pass the test suite.So here is an idea: try to work out how the expectations of Git can be met, maybe by making minor adjustments to the MSYS2 runtime, and once that is done, modify Git for Windows'
mingw-w64-git
package in a way that the identical definition can be used inmsys2/MINGW-packages
(one thing that would obviously need to be changed is thatmingw-w64-git
must not put agit-bash.exe
into the root directory 😁).Are there people interested in working with me on this project?
EDIT: Here is an analysis of the deviations between MSYS2's and Git for Windows' flavor of the MSYS2 runtime:
find
on a FAT file system and should probably go into MSYS2 as-is${var:-hello}
and${var-hello}
after settingexport var=
). The fix might even be welcome in the Cygwin project. -> Allow empty-valued environment variables to be passed to non-MSYS programs msys2-runtime#101MSYS2_ENV_CONV_EXCL
andMSYS2_ARG_CONV_EXCL
variables, this commit introduces a poorly-named but at least dirt-easy-to-useMSYS_NO_PATHCONV
variable to stop the MSYS2 runtime from misinterpreting command-line arguments starting with a slash as referring to an absolute Unix-y path that needs to be converted to a valid Windows one (thinkcmd /?
).uname
report the commit from which the MSYS2 runtime was built. This should go into msys2/msys2-runtime; We may eventually even want to contribute this to the Cygwin project, they may like it, too.There are a couple of challenges with this idea outside of the MSYS2 runtime:
mingw-w64-git
installs a/git-bash.exe
(and other files that are most inappropriate for MSYS2). We will need to split them into their own package, e.g.mingw-w64-git-for-windows-root
, that only gets built and installed in the Git for Windows project./home/<user>
(which would be unwritable in an installed Git for Windows). There is really no good way to override this other than editing files that are owned by MSYS2's packages (such asfilesystem
). Git for Windows does this via a hack: the post-install script of themingw-w64-git-extra
package performs those edits as needed. It would be nice if we found a non-hacky solution for these modifications.CURL_SSL_BACKEND
forcurl.exe
,http.sslBackend
for Git). The MSYS2 project insteads builds various flavors oflibcurl
; The user has to decide which flavor to install and then cannot switch between them at runtime. I am ready to bite the bullet and adjust Git for Windows' libcurl to align with MSYS2's paradigm (and I think I found a hacky way to still sort of support runtime-switching).Beta Was this translation helpful? Give feedback.
All reactions