Feature Request: Supported way to use Git for Windows with full MSYS2 features

[mikebeaton]

This is a feature request, of sorts, which is why I'm not using the standard Issue template. I hope I understood correctly from your homepage that this is the right place for feature requests, so that that's okay!

So, I understand that Git for windows is built on MSYS2, which is itself build on Cygwin. Some (but certainly not all) users of Git for Windows are going to want additional Unix-like commands and features (which they might typically get by installing MSYS2 or Cygwin), above and beyond the ones which Git for Windows needs and provides (see, e.g., this Stack Overflow question).

Because of that, it would be great to have a supported version of Git for Windows which adds just what you need if you already have MSYS2 installed and running. Or a supported version of Git for Windows with MSYS2 pacman included, so that users who want/need to do so can add features. Does something like that exist? If not, is there a chance of it? (And, of course, are there maybe strong technical reasons why it isn't currently done like this?)

If that doesn't currently exist (as I think I understand correctly that it doesn't), then is it correct to say that a user who wants this either has to have two separate MSYS2/Cygwin installs on their machine (one for the pacman features plus one for Git), or else that they have to roll their own version of what I'm talking about, using the Git for Windows development environment? I think it's worth emphasizing that obviously that latter process would be considerably more complex than just installing a full MSYS2 plus installing Git for Windows separately. (And as far as I'm aware, there'd be no particular documentation about how to use the Git for Windows SDK to achieve this - again, apologies if this is not correct! - so that each user who wants this would just have to sit down and work it out for themselves - which I'm sure is perfectly do-able, but takes time in our busy world! - independently.)

Thank you - for what is anyway, already (obviously!) an awesome project!

[PhilipOakley]

Hi Mike,

The current project provides (as I think you know), at least from my point of view, two operating style, both focussed on 'regular' windows users and developers. These are:

1. the Git-for-Windows standard install from via the gitforwindows.org - download button, which installs in the 'C:\Program Files' directory, and

2. the GfW Software Development Kit (SDK) from the Download Git for Windows SDK button in the #Contribute section of gitforwindows.org.

Both the Git-for-Windows standard install and the SDK installs each try to be fairly minimal, while self contained, to avoid too much bloat, but it's a judgement call.

Importantly, both presume to be able to start from scratch on a users machine, so install their own [MSYS2] shim layer codes between the Windows OS and Git, which was expecting to run on a Linux/Posix OS.

If I understand correctly, you would be interested in a 'Third way'. One in which the user (e.g. yourself) already has a personal Linux/Posix layer installed, and then wishes to install Git (for Windows) on top of / into that environment.

It is certainly something you could have a look at, and would probably be of benefit to the project (especially if it encourages others in the same position to contribute). It probably means carefully splitting the SDK install into two/three parts, one for the OS shim layer (MSYS2), and then the support functions (e.g. those via pacman), and finally the main Git for Windows part (which complies the current version etc).

With such a split, (in my head) it then becomes moderately easy to have a method for starting in the second part and 'simply' checking that the necessary support has been already installed, and installing them if necessary.

That all said, the 'simply' part is likely to be tricky because of various compatibility issues (many and various) that have occurred, such as the particular perl version needed for svn (inc testing) and all the console programme nuances.

It maybe that the first step is to get it working for at least one person once (e.g. yourself) which would show proof of concept, and may be an instruction sheet for others with their own particular setups.

I've written it all out long hand both for the lurkers and just in case there was a nuance that I might of misunderstood.

--
Philip

[mikebeaton]

Thanks Philip, I should look at it!

I may have misunderstood a couple of things:

1. Since Git for Windows SDK is described as the "Build environment for Git for Windows", I was assuming that upon installing Git for Windows SDK I wouldn't have any kind of Git (or possibly even MSYS2?) installed, but would then be ready to start building things

2. The Git for Windows SDK install seems pretty huge (certainly compared to installing just Git for Windows), I stopped it about half way through since (as based on the above assumption) I wasn't planning to download a large build environment and then build my own, unsupported custom version of GfW - which I what I ended up assuming I was going to have to do

If either or both of the above embody one (or more, serious or otherwise!), misunderstanding(s), please set me straight!

[PhilipOakley]

Hi Mike,

to answer the couple of Questions:

1. Typically a windows user/developer will have both the GfW regular install (the safe release version), and the SDK which has it's own compiled version.

2. Yes, the SDK does feel huge. But it is a fully fledged dev environment (you already have most of it but installed at a different path, the horrors of duplication...), and that includes the compilers and test suite and everything needed to create a Git release. And the install script will confirm success by at least compiling the git source code.

The place to start (for the SDK) is https://github.com/git-for-windows/git/wiki/Technical-overview and various of dscho's replies to other issues that mention the SDK ;-)

You may also want to look at https://github.com/git-for-windows/git/wiki/Install-inside-MSYS2-proper - this may better reflect your current situation!

Because of the way Windows/MSYS2 does it's drive mappings, each of the git install has their own personal 'root', which can cause confusion.

[pelepelin]

I think the idea is converting an existing GfW environment into GfW with Pacman without installing MSYS2 or GfW SDK. I know there are instructions how to convert MSYS2 into GfW, but if I already have GfW and want a package or two (for example, I need rsync), why bother installing MSYS2 or full SDK?

[dscho]

I think the idea is converting an existing GfW environment into GfW with Pacman without installing MSYS2 or GfW SDK.

@pelepelin Please acquaint yourself with the implementation details, and be ready to put in some effort to drive your requested feature, before suggesting something like that. There is a reason why MSYS2 does not install into C:\Program Files: Pacman needs write permissions to update packages.

Having said that, if you are comfortable to run Pacman as administrator, you can turn a Git for Windows installation into a Pacman-based system. You will have to learn about the way Git for Windows is built from Git for Windows' SDK, how Pacman organizes its metadata, and you will have to implement a program or script to combine the information from /etc/package-versions.txt with the files present in https://github.com/git-for-windows/git-sdk-64 (or -32) to re-initialize the Pacman system in a full Git for Windows installation.

If you are not comfortable driving this effort yourself, all you can do is hope that somebody else with a similar wish will come along who has more energy to push forward on that feature request.

why bother installing MSYS2 or full SDK?

Because that would be the easiest for you.

[mikebeaton]

Just to give an update, I personally won't have time to work on this any time soon. I see it's been closed in any event. [EDIT: Apologies, I misread the 'Closed' tag on #1950 above as applying to this issue.]

Part of the reason for raising the issue was just to double-check that I had understood the situation correctly - to check that I wasn't going to be told "you can already do this! see here!", for instance, and to check that such an effort wasn't already in progress.

@PhilipOakley you've very helpfully laid out exactly what would need to be done.

Fortunately (or unfortunately?) the existence of WSL makes this less urgent for me at least, since my essential underlying aim was just to have as few Un*x shells as possible in order to achieve i) a working command line git and ii) at least one Un*x shell with a package manager! (And, since GfW is indeed based on a Un*x for Windows system which - in its full install - does have a package manager, I was wondering what would be involved... etc.)

[dscho]

I personally won't have time to work on this any time soon.

And this is the story that I hear about this over and over and over again. Why do you expect others to have that time?

I guess I need to open a new, "up for grabs" ticket with a real splendid idea how we can make it easier for users to get started with a minimal MSYS2 system based on Git for Windows, and even easier for them to contribute toward making this setup something that can be maintained sustainably.

By "sustainable maintenance" I mean: the maintainer (yours truly, pleasure to meet you) reviews and accepts contributions.

[mikebeaton]

@dscho I don't expect you to have that time. I was just letting you know that, even though I raised the issue, I don't.

I asked about the issue before I realised that WSL already let me do what I actually wanted (as described above). If that hadn't been the case, I might well have carried on here. So sorry about that. And, it goes without saying, but, thanks for all your extremely valuable work on a very useful project.

[pelepelin]

Well, IIRC for me the way to use full environment was something like following the instructions to install SDK over the existing GfW and then remove one of SDK-specific profile files to revert the PS. Or maybe I forget and actually I've copied file by file until pacman started working.

Running package manager with admin rights is not a problem, since it is not an everyday task.

[dscho]

Running package manager with admin rights is not a problem, since it is not an everyday task.

I think you underestimate this.

[mikebeaton]

I posted the link to the GfW wiki page Install inside MSYS2 proper (which @PhilipOakley provided above) in a StackOverflow answer about this, and it seems that at least a few people are finding that that is exactly what they were looking for, in this situation.

[dscho]

@mikebeaton thanks. I hope that this does not add unduly to my maintenance burden, though. Here's hoping for the best!