git-wrapper: support MSys2

[dscho]

The original purpose of the Git wrapper is to run from inside Git for
Windows' /cmd/ directory, to allow setting up some environment variables
before Git is allowed to take over.

Due to differences in the file system layout, MSys2 requires some
changes for that to work.

Signed-off-by: Johannes Schindelin [email protected]

[dscho]

@sschuberth could you have a quick look? It's really a tiny patch, and my recent patches really benefited from your review.

[dscho]

Oh, I just got another idea: We could replace the git-bash.bat and git-cmd.bat scripts with copies of an enhanced Git wrapper, too...

[sschuberth]

Ok, I'm fine with the PR, but I do not merge yet as you said:

We could replace the git-bash.bat and git-cmd.bat scripts with copies of an enhanced Git wrapper, too...

And I'm unclear whether you want to do this as part of this PR.

[dscho]

We could replace the git-bash.bat and git-cmd.bat scripts with copies of an enhanced Git wrapper, too...

And I'm unclear whether you want to do this as part of this PR.

Have a look at 18f6085 and 70bfdb7 (part of this PR) :-)

[dscho]

@sschuberth git-bash.bat is what the msysGit-based portable application renamed msys.bat to, for clarity: users did not know that msys.bat would launch a Git Bash for them. I guess, Git Bash.vbs' purpose was exactly the same, but it was not my original intention to replace it, but to skip it instead when upgrading to MSys2.

[dscho]

I don't think the information which terminal program to use (be it mintty or something else) should go to git-wrapper in the first place.

But it must. Just like we encode the knowledge about "if you are called as a builtin, reconstruct the command line in the following manner and call the git.exe in the same directory" and "if you are called as git.exe, assume that you are in /cmd/ and call the real git.exe after setting up these environment variables: ...", we have to encode the knowledge about what to do when called as git-bash.exe.

But how about at least renaming the executable from git-bash.exe to git-mintty.exe to make the dependency on mintty more obvious?

I thought about that. From a purely technical point of view, you are right. However, from the users' point of view, it would be a terrible idea: how many users know what mintty is? And how many of those users would expect the Bash to show up when you run git-mintty? No, we cannot do that.

A better idea would be to handle command-line options. But since we are essentially reusing the Git wrapper executable for all the builtins, for /cmd/ and now also for git-bash and git-cmd, that means that every additional code we put into the Git wrapper will inflate our disk usage times 112.

Don't we then need to build a git-cmd.exe, too, analogous to 857b1a5?

Just as we simply copy git-wrapper.exe into the appropriate locations under the respective names (such as /cmd/git.exe, /mingw??/libexec/git-core/git-log.exe, etc) we can easily copy git-bash.exe using the target file name git-cmd.exe.

The only purpose of 857b1a5 is to have the Git wrapper compiled as a GUI program (in addition to the console program that is compiled to the name git-wrapper.exe). If we just copy over git-wrapper.exe to git-bash.exe and execute it, say, by double-clicking the icon in the Explorer, we end up with two console windows: a Win32 console and the mintty one. Sorry that my commit message sucks so bad, I will fix it.

[dscho]

Another couple of thoughts:

• I considered to encode the information what console to call in the file name itself. For all the reasons git-mintty.exe would make for a bad user experience, I rejected this.

• There is another option, still, for specifying what terminal to call, and how: an external configuration file. At first, I thought that this might not be a good option because it means an extra file access every time it is started. However, thinking about it again, the git-bash.exe executable will not be started all that often, right? I'd expect it to be called only once per Git Bash session, after all. It still would bloat the git-wrapper.exe code unnecessarily, which brings me to my next point:

• More and more I think about it, our Git fork should not know that much about our relying on MSys2. It is okay to support it, but we also make a point of trying to be as backwards-compatible as possible, and who knows, maybe somebody makes Git for Windows work nicely within Cygwin, too, one day. So I think that it might make sense to make the git-wrapper.c code a little bit more flexible by refactoring the builtin and /cmd/ specific handling into a separate function, and then guard that function by something like:

  #ifdef CUSTOM_GIT_WRAPPER
  #include CUSTOM_GIT_WRAPPER
  #else
  static int git_wrapper_handler(...)
  {
  }
  #endif

  That way, we can provide our own handler source code in the mingw-w64-git package -- which is specific to MSys2. This source code would then be used in the following way in the PKGBUILD's build() function:

  gcc -o git-bash.exe -Wall -mwindows -DCUSTOM_GIT_WRAPPER=\"git-bash-handler.c\" src/compat/win32/git-wrapper.c  -lshell32 -lshlwapi

Please tell me what you think about this plan.

[sschuberth]

But it must.

Sorry, I still do not get why that should be the case. IMO the only thing a git-bash.exe should do is to open a regular Windows console window with the environment set up for Git and using Bash as the interpreter. Very similar to how git-cmd.exe opens a regular Windows console window with the environment set up for Git and using Cmd as the interpreter.

If someone wants to use mintty with git-bash.exe, that someone would nee to create a shortcut / minttyrc that runs mintty -i /usr/share/git/git-for-windows.ico git-bash.exe. I'd simply prefer git-bash.exe to be usable with any of mintty, ConEmu, ConsoleZ, not by hard-coding support for all of them, but none of them (and configure it outside).

[dscho]

the only thing a git-bash.exe should do is to open a regular Windows console window with the environment set up for Git

But then you have two terminal windows: the real terminal you wanted, and a Win32 console that waits until the other terminal window is closed.

Not what we want.

[sschuberth]

But then you have two terminal windows

What? No, why? 857b1a5c178001c578a0433cec8bcd763b4a4f6a builds git-bash.exe as a windows program, so it will not allocate a console for itself, but the spawned Bash will, resulting in only a single console window, no?

[dscho]

But then you have two terminal windows

What? No, why?

Because of what you asked for:

to open a regular Windows console window

[sschuberth]

That referred to the regular Windows console window that Bash opens for us. I was just meaning to point out the regular, i.e. not mintty or any tabbed console wrapper.

[dscho]

Oh, and you reminded me of something I should change, still, no matter what: if mintty.exe is not there, we should use %comspec% /k instead of usr\bin\mintty -i <ico>.

[dscho]

That referred to the regular Windows console window that Bash opens for us. I was just meaning to point out the regular, i.e. not mintty or any tabbed console wrapper.

Right. And I think we have to separate out the git-bash.exe stuff from the Git wrapper as a consequence, because it is going to be even trickier than that.

For example, if you double-click the git-bash.exe icon, you would want to switch to the home directory. But if you want to run, say, Git Bash Here you would not want to switch to the home directory. That means we have to add command-line flags. That is only necessary for the git-cmd and git-bash executables, not the Git wrapper, so it makes no sense to add that code to all of the builtin drop-ins.

And if we are already going that route, we might just as well add that configuration file handling you were implicitly asking for.

[sschuberth]

[...] that configuration file handling you were implicitly asking for.

No, I was not asking for that. When I was referring to configuration files, I meant those of the specific console wrapper program to use. I'm not a fan of configuration files in this case, but rather command line arguments.

[dscho]

[...] that configuration file handling you were implicitly asking for.

No, I was not asking for that. When I was referring to configuration files, I meant those of the specific console wrapper program to use. I'm not a fan of configuration files in this case, but rather command line arguments.

We are trying to make it easy for users, not difficult. Forcing them to type into some command-line window

c:\path\to\git-bash.exe --command-line usr\bin\mintty -i c:\path\to\icon.ico bash --login -i

every single time they want a Git Bash is kinda, uhm, not what I want. Like, at all. The whole, entire point of having a git-bash.bat or git-bash.exe is to have a double-clickable icon that gets you a Git Bash. Fast. Like, really without having to do anything else.

So either it is a configuration file (easy to edit) or it is a resource embedded in the .exe (harder to edit) or it is a string that is appended to the .exe (obscure) or something else. But command line parameters are the worst possible solution for this, short of not having a git-bash.exe at all.

[sschuberth]

Code like

git-bash.exe --command-line usr\bin\mintty -i c:\path\to\icon.ico bash --login -i

should simply be but into a .bat / .cmd / .vbs file (that is easy to edit) that we ship.

[dscho]

Code like

git-bash.exe --command-line usr\bin\mintty -i c:\path\to\icon.ico bash --login -i

should simply be but into a .bat / .cmd / .vbs file (that is easy to edit) that we ship.

The problem is of course that every .cmd file opens a Win32 console, when double-clicked. That was the entire reason why I bothered to patch up the Git wrapper in the first place.

[sschuberth]

Yeah, scratch .bat / .cmd, that was wrong, I meant only .vbs. Just double-click the "Git Bash.vbs" in the MSYS1-based SDK to see how it opens only a single console window.

[dscho]

But we cannot change the icon of the Git Bash.vbs. Not so nice, either.

[dscho]

The idea I am following right now is to add conditional code (switched on when the -mwindows version is compiled) that uses string resources embedded in the .exe file to override what the Git wrapper calls. Additionally, this conditional code will also contain a subcommand with which you can edit those resources. Something like this:

cp git-bash.exe res-edit.exe
./res-edit icon git-bash.exe git-for-windows.ico
./res-edit command git-bash.exe 'usr\\bin\\mintty.exe -i /usr/share/git/git-for-windows.ico /usr/bin/bash --login -i' '@@COMSPEC@@ /C "@@EXEPATH@@\\usr\\bin\\bash.exe --login -i"'

[dscho]

So here is the code for the updated Git wrapper. I decided to use the edit-res.exe name to avoid confusion with the freeware ResEdit. But the idea is essentially the same: copy git-bash.exe edit-res.exe and then you can edit the icon and the command line(s). If you specify more than one command-line, the wrapper will execute the first one whose first argument is an actual file.

[dscho]

Okay, this is it. Now I am happy.

[dscho]

@sschuberth @t-b unless you have strong objections, I will merge this tonight, along with git-for-windows/MINGW-packages#4.

[sschuberth]

unless you have strong objections, I will merge this tonight

Ok, sarcasm of my previous comments aside. Again, I'm sorry I have to say this, but I do think this series does some very wrong things. But this is just my personal opinion, and I currently do not have the time to come up with a better solution, which probably is what you would be asking me for if I "strongly object" to merge.

So it's basically your opinion against mine as I guess @t-b will not have time for a review. Since you're pushing for the new release, I will not "strongly object", but just "object", hoping that I'll never have to deal with this code once it's merged.

[dscho]

Seeing that we exhausted all available constructive suggestions, at least for now, I am going to merge. We can always revisit the issue should somebody come up with a clearly superior solution.

[sschuberth]

meeting your vocal objections as to hardcoding mintty, without any indicator what could replace this working solution, my suggestion of a configuration file also being shot down

It did indicate what I'd preferably do like to see this replaced with: not hardcoding anything, and also not configuring anything, by not putting any terminal program related code into git-wrapper in the first place.

when I finally spent 2h reverting my changes and going for a resource-based solution, and another four hours trying to find an Open Source command-line resource editor we could ship, only to find that there is none

I'm sure you understand that I won't endorse a solution that I regard as sub-optimal just because it took you a long time to implement. I was your choice to come up with a resource-based approach (and yes, I did propose another alternative to configuration files: command line arguments), so you have to deal with the consequences of your choice.

It is not the sarcasm that I mind. It is the fact that those objections are in want of constructive arguments.

I believe my linked comments were constructive. Maybe they did not help to make you solve your problem, or solve in a way that you like it so be solved, but saying that a problem is not worth solving in this context (i.e. the problem of configuring a terminal program) is also constructive criticism IMO.

[dscho]

I'm sure you understand that I won't endorse a solution that I regard as sub-optimal just because it took you a long time to implement.

And I am sure that you will eventually understand that I won't endorse objections that come without constructive suggestions how to do things instead.

I did propose another alternative to configuration files: command line arguments

I already pointed out why command-line arguments are not an option: they cannot be passed via double-clicking.

saying that a problem is not worth solving in this context (i.e. the problem of configuring a terminal program) is also constructive criticism IMO.

It would be constructive, had you not known the reasons for abandoning the .cmd and .vbs scripts in the first place. But you do now, and simply ignoring those reasons does nothing to invalidate them.

In any case, I am bowing out of this discussion until a time when I see a compelling idea how to address the list of bullet points (that I just edited) above.

[sschuberth]

they cannot be passed via double-clicking.

And in response to that I was saying that we should just have a .vbs file anyway, but you again objected as a .vbs cannot have a custom icon.

had you not known the reasons for abandoning the .cmd and .vbs scripts in the first place.

Please correct me if I'm wrong: As I see it, the only reason not to use a simple .vbs is that it cannot have a custom icon, right? If so, that's again where I would say: Solving the problem of the missing icon by implementing the logic into the git-wrapper is not worth the effort.

To recap, my proposal is:

• Make the git-wrapper again as thin as it was before. It should only serve as a wrapper to the main git.exe, setting up any necessary environment variables to be able to run Git independently of the shell environment it was started from.
• Continue to use copies of the git-wrapper as aliases for built-ins.
• Create Git Bash.vbs and Git Cmd.vbs convenience scripts that start Bash / Cmd environments that have Git in PATH, i.e. properly Git set up for command line work.
• Do not assume the use or preference of any terminal like mintty, ConEmu, ConsoleZ etc. Users who want to use any of these would need to set up their preferred terminal in a very similar way to what the Git Bash.vbs / Git Cmd.vbs scripts do internally.

Did I miss to cover any of the requirements?

[kblees]

Seeing that we exhausted all available constructive suggestions, at least for now, I am going to merge.

@dscho It leaves me kindof speechless that you merged this in mid-discussion, while there are objections by no less than three contributors, including constructive suggestions such as using shell links.

I would like to ask you to keep the emotional payload out of your future comments, though, especially when they run the danger of making up the majority of the contribution.

You've added more than 300 lines of code without a single line of comment, which is completely un-maintainable.

A very seasoned Windows developer may suspect that your icon parsing code is based on the [GRP]ICONDIR and [GRP]ICONDIRENTRY structures documented in [1] and [2]. However, you renamed everything so that it is harder to understand or to find that documentation.

Therefore, the term "ugly hack" seemed appropriate to me. It was not my intention to sound emotional or to hurt your feelings.

Btw., the icon parsing code in particular seems to be copied verbatim from [3], but without including copyright and licensing information from the source file / project.

[1] https://msdn.microsoft.com/en-us/library/ms997538.aspx
[2] http://en.wikipedia.org/wiki/ICO_%28file_format%29
[3] https://github.com/imagej/imagej-launcher/blob/master/src/main/c/exe-ico.c

[kblees]

Windows applications are typically configured through registry settings, not by modifying resources of .exe files.

Please stop a second to think about the portable application, and also about having a 32-bit and a 64-bit installation next to each other. Yep, the registry idea does not make sense.

I've never seen an application that is configured by modifying its own string resources. This simply doesn't work for end users without write access to the installation directory.

I also don't see what the last three patches buy us that cannot be done with shell links or .cmd/.vbs files (all easily configurable / editable via standard Windows mechanisms).

Please read this comment and that comment, part of this very Pull Request.

These comments don't mention shell links, which can have arbitrary icons and can execute arbitrary commands or scripts without opening a console window.

• we need a Git Bash that has a manifest, an icon, launches the MSys2 Bash, is able to run in mintty and can be configured to run in different terminal emulators

Users typically don't start applications by browsing the C:/Program Files tree, so IMO having an icon is not a strict requirement. Its not even an issue as shell links can have arbitrary icons.

Supporting mintty or other terminal emulators is a completely separate issue from supporting MSys2. Mintty reportedly has serious problems with native console applications [1], so we cannot use it - at least not by default. Besides, most Windows users will be more familiar / comfortable with a 'real' console window.

[1] https://code.google.com/p/mintty/issues/detail?id=56

[PhilipOakley]

minor bike shed:

Users typically don't start applications by browsing the C:/Program Files tree, so IMO having an icon is not a strict requirement. Its not even an issue as shell links can have arbitrary icons.

While it isn't common to browse to the C:/Program Files tree, I do find I need to do it moderately often on my work PC because (exploring & editing) the start-menu is hidden to me (corporate rule), such that say Notepad++ (which I have installed) doesn't show on the regular Start menu. That means I need to navigate the tree as discussed - for Notepad++, I've added for myself a desktop short cut and a pinned task bar shortcut, so I don't need to drill for that, - but there are other programs I use less frequently where I keep needing to drill down to 'cos I know I have them but the PC's start menu won't show them :-(

As long as it's possible to navigate to the tree, it's not really a problem that it doesn't have the right icon, so it's only a cosmetic issue (aren't they the worst sort of customer issue ! ;-).

[dscho]

@dscho It leaves me kindof speechless that you merged this in mid-discussion, while there are objections by no less than three contributors, including constructive suggestions such as using shell links.

The word "constructive" means something different in my book.

Also: in the meantime, I reverted those changes (two days ago, no less).

As to the shell links, their targets are absolute directories. That does not work for portable applications.

Mintty reportedly has serious problems with native console applications [1]

This has been discussed already. The point you are making is that not every interactive console program works in mintty. But that is something completely different from what Git for Windows is trying to offer!

Users typically don't start applications by browsing the C:/Program Files tree, so IMO having an icon is not a strict requirement. Its not even an issue as shell links can have arbitrary icons.

While it isn't common to browse to the C:/Program Files tree, I do find I need to do it moderately often on my work PC

Even if there are legitimate reasons to browse Program Files and to rightfully expect the executables to be non-amateurish, I feel compelled to repeat myself -- again -- that a major use case is the portable application. Therefore, while certainly intended to be helpful, I once again recall your attention to the non-exhaustive list of needs of Git for Windows.

[PhilipOakley]

Hi @dscho,
Sorry if I was at cross purposes on the 'C:/Program Files' discussion. I was talking relative to an installed version rather than the portable version. Apologies for any confusion.

[dscho]

@PhilipOakley no apologies necessary!

[kblees]

As to the shell links, their targets are absolute directories. That does not work for portable applications.

Relative shell links can be created by specifying %systemroot%\explorer.exe / %systemroot%\system32\cmd.exe / %systemroot%\system32\wscript.exe as link target, with the relative path of the executable / script as argument. At least this has always worked for me...

Mintty reportedly has serious problems with native console applications

This has been discussed already.

Where? All such discussions that I could find in the ML seem to conclude that we cannot use mintty.

But that is something completely different from what Git for Windows is trying to offer!

I always thought that Git for Windows was about porting git to the native Windows platform. IMO this includes working seamlessly with native Windows applications. But I guess I must have been wrong.

I also thought that the MSys(2) dependency was just because we don't have a working mingw-bash and mingw-perl (yet?). IMO one of the biggest issues we're facing ATM is the necessity to rebase dlls, potentially after each Windows patch day, and even without guarantee that it'll work afterwards.

[dscho]

I always thought that Git for Windows was about porting git to the native Windows platform

Exactly. Git. Not a development environment where you can run an unmodified interactive Python console. Just Git.

[dscho]

Mintty reportedly has serious problems with native console applications

This has been discussed already.

Where?

Several times: https://github.com/git-for-windows/git/issues?utf8=%E2%9C%93&q=mintty+terminal

[dscho]

As to the shell links, their targets are absolute directories. That does not work for portable applications.

Relative shell links can be created by specifying %systemroot%\explorer.exe / %systemroot%\system32\cmd.exe / %systemroot%\system32\wscript.exe as link target, with the relative path of the executable / script as argument

So in order to fix a flaw such a kludge should be introduced?

Seriously, I really want a clean solution.

Batch files are okay for prototyping, but they come with plenty of downsides compared to real executables. There are enough reasons listed in the commit message that replaced /cmd/git.cmd with the Git wrapper. There is the fact that it looks amateurish when it has not even an icon, and certainly lacks a manifest and embedded version information. Plus, we cannot push for Git's shell scripts to be converted to builtins on the one hand and then refuse to do the same for Git for Windows.

It is a nice hack to use %systemroot%\... in shortcuts to work around the issue. Apart from those shortcuts still being unable to set environment variables before calling anything else, it's still a hack, though. I.e. something else than a clean solution.

[dscho]

It leaves me kind of speechless that you merged this in mid-discussion [...]

There was no discussion. Instead, there was completely unnecessary incendiary language. And quite a bit of criticism without suggesting any better alternatives.

To protect my time and my enthusiasm for this project, I therefore cut this whatever-you-want-to-call-it short.

[sschuberth]

that a major use case is the portable application

@dscho I'm questioning that the portable application is such a major use case. It just happens so that you like it and GitHub wants one. Unfortunately our download stats from Google Code seem to be gone, but IIRC portable downloads were just a small fraction of full installer downloads.

I always thought that Git for Windows was about porting git to the native Windows platform.

@kblees Same here. And I'd like to take the change of the Git Merge conference in Paris to discuss what "Git for Windows" really should be. To me, it means to bring the best Git experience to Windows, in general. It does not necessarily mean to me to port the existing main Git implementation to Windows, although that's we have always been doing. It could also mean to come up with a new Git client based on libgit2, for example.

just because we don't have a working mingw-bash

@kblees There will never be a mingw-bash. I had been looking into existing native Windows implementations of bash in the past to get rid of MSYS altogether, but nothing I found was promising / usable.

Once you realize that there will be no execution of Git shell scripts without bash, and bash requires MSYS, but we actually do not want to depend on MSYS, you come to the conclusion that we need to get rid of the shell scripts. Now, that could mean many things, from re-implementing them as C code (which is why I like the GSoC proposal to make pull and am builtins so much) over building upon another Git implementation that does not depend on shell scripts, to starting a new implementation of Git from scratch (maybe in C++, finally).

IMO one of the biggest issues we're facing ATM is the necessity to rebase dlls

@kblees We don't have that issue with 64-bit MSYS2 / Git due to the bigger address space anymore, which is why I think we should focus on that one currently.

Exactly. Git. Not a development environment where you can run an unmodified interactive Python console. Just Git.

@dscho While strictly speaking you're correct, this just won't work IMO. Once you ship and promote mintty as the shell for Git, people will start using that shell for any of their daily development work on Git hosted projects. I guess no command line user would want to switch shells during their work on e.g. a Ruby project depending on whether they want to run Git or the interactive Ruby interpreter.

I'm repeating myself saying that if we ship mintty, we must be prepared to support it. And when @dscho agreed to support it, I guess he only meant to support it for use with Git. But that won't be enough. You'd also have to deal with all the issue reports about interactive Ruby (or similar) not working in mintty.

[kblees]

As to the shell links, their targets are absolute directories. That does not work for portable applications.

Relative shell links can be created by specifying %systemroot%\explorer.exe / %systemroot%\system32\cmd.exe / %systemroot%\system32\wscript.exe as link target, with the relative path of the executable / script as argument

So in order to fix a flaw such a kludge should be introduced?

I agree that its a kludge, nevertheless one that Windows users are familiar with (just google "relative shortcut"). The big advantage is that shell links can be configured via normal Windows mechanisms (right click - properties...).

There is the fact that it looks amateurish when it has not even an icon, and certainly lacks a manifest and embedded version information.

Icon, manifest and version info can all be supplied at compile time.

My main issue is with configuring the command to launch via string resources. E.g. to change the terminal from mintty to native console or vice versa, you would neet to:

• Have write access to the executable(s)
• Copy git-wrapper.exe to edit-res.exe
• Call edit-res with the command to launch specified on the command line, with all special characters correctly escaped (where escape rules depend on whether you call edit-res from cmd or bash)
• Use @@ instead of % for environment variables
• Use e.g. Visual Studio to check if the command correctly made it into the executable

IMO this is far from a clean solution, and no Windows user would remotely expect it to work that way...

[dscho]

My main issue is with configuring the command to launch via string resources.

I fear that you completely misunderstood the purpose of ./edit-res.exe. From your comments I deduce that you think it was intended for use by each and every end user.

That is incorrect. The intended use case was for our very own installer, so that there can be a page asking the user "Which terminal do you want to use?" and then adjusting git-bash.exe accordingly.

At this point, the horse has been dead for five days already, though, half an eternity in terms of the current development speed of Git for Windows).

A more constructive thing to do than to argue against a change that has already been taken out (so there is really nothing any longer to argue against) might be to install the development environment and get cracking with some performance tests of the msys2-runtime to determine where we can improve the speed.

[tkelman]

There will never be a mingw-bash. I had been looking into existing native Windows implementations of bash in the past to get rid of MSYS altogether, but nothing I found was promising / usable.

Once you realize that there will be no execution of Git shell scripts without bash, and bash requires MSYS, but we actually do not want to depend on MSYS, you come to the conclusion that we need to get rid of the shell scripts.

@sschuberth Do you actually need full-fledged bash, or would a simpler posix shell be sufficient? For Debian or other distributions where /bin/sh is not bash, have most of the git shell scripts been ported to avoid bashisms by now? If so, the win32 port of busybox https://github.com/rmyorston/busybox-w32 could be worth looking at (for the future - not right now, as msys2-based git for windows is very nearly release-worthy). It doesn't help for the development environment since you probably also need a posix-style gmake to compile git, but it might be good enough for git's shell scripts at runtime? I'm not sure.

[dscho]

have most of the git shell scripts been ported to avoid bashisms by now

Not "by now". Git's shell scripts always have been POSIX shell scripts (except when there were bugs, and those bugs have always been fixed swiftly AFAIR).

I actually looked at BusyBox a couple of years ago and it was not ready back then.

But even if you solve the POSIX shell problem (and note that the shell scripts still assume POSIX semantics, such as: POSIX paths, POSIX-type signal handling, POSIX process control), we still need a Perl with Subversion bindings. You are certainly welcome to try your hand at getting that beast to compile against a MinGW Perl...

[tkelman]

Git's shell scripts always have been POSIX shell scripts

Great, I was under that impression last time I grepped git's source code for /bin/bash and didn't find anything. So "there will be no execution of Git shell scripts without bash" is not correct then.

try your hand at getting that beast to compile

I don't know perl modules all that well, but which beast are you referring to exactly? Do the subversion bindings get built as part of subversion itself, or are they a separate cpan module? Is the current development state of git-for-windows using the msys2 perl then? edit: nevermind, answered my own question in the affirmative, looking at https://github.com/git-for-windows/MINGW-packages/blob/master/mingw-w64-git/PKGBUILD

[dscho]

So "there will be no execution of Git shell scripts without bash" is not correct then.

To qualify that statement, you would have to demonstrate that it works with, say, BusyBox' dash.

answered my own question in the affirmative, looking at https://github.com/git-for-windows/MINGW-packages/blob/master/mingw-w64-git/PKGBUILD

That file does not really say anything about the question how Perl bindings for Subversion need to be provided, nor the technical details how to build them.

The git svn command is a Perl script that expects the SVN.pm Perl package to be available. This package is an optional build product of the native Subversion build because it actually requires all of those .dll files.

[sschuberth]

Do you actually need full-fledged bash, or would a simpler posix shell be sufficient?

@tkelman As @dscho has already said there never were supposed to be bashisms in Git shell scripts. In that context a simpler shell, like dash, should indeed be sufficient, but again as already mentioned that yet needs to be proven.

I was just saying bash initially as that's the shell we ship. I was not meaning to say that Git shell scripts depend on bash.

[tkelman]

To qualify that statement, you would have to demonstrate that it works with, say, BusyBox' dash.

True. I just tried it - in busybox's dash, with libexec/git-core and bin from a Portable Git 1.9.5-preview20141217 added to the path, running the libexec/git-core/git-pull shell script worked nicely. That's of course a far cry from passing the test suite or anything, path handling in particular is different when you don't have the msys translation happening for you, but at least very basic things should be feasible.

That file does not really say anything about the question how Perl bindings for Subversion need to be provided, nor the technical details how to build them.

Right, I only meant the last bit of my question, that the MSYS2-based git for windows currently looks like it's using an msys2 perl rather than a mingw one. Should a separate tracking issue be opened for centralizing information on what would need to be done to switch to a mingw perl?

[dscho]

Should a separate tracking issue be opened for centralizing information on what would need to be done to switch to a mingw perl?

I'd rather have a preliminary PR with some initial work done on that front instead of a ticket that is most likely going nowhere ;-)