why does sdk-installer start git-bash.exe?
x3nb63 opened this issue · 5 comments
I want automated installations of git-sdk, and got quite far:
.\git-sdk-installer-1.0.8-64.7z.exe -o "C:\git-sdk-64" -y
installs nicely, but once its done setup-it-sdk.bat does
@START /B git-bash.exe
... and that hangs all my automation. Its window isn't even visible when its started by my automation system. I just found that by noticing the process, then killing it and observed the installation to continue.
Can that line be removed?
Or can the "-y" flag from the installer skip it?
If you don't want the Git SDK Bash to start immediately, you are not using the installer in the intended way. I created that installer specifically to help Git for Windows' contributors to develop and test patches. If you found a way to automate that, I would be very interested in hearing more about it.
If all you want is a Unix-like environment, you are most likely better off using MSYS2.
I see.
yes, its used for something else: building. Its got things msys2 does not have. Can't say what cause I did not do that part.
Dont know what testing a patch means in your case. What I do is have a Concourse worker run scripts in the git-sdk installation, like so:
at CWD = "C:\git-sdk-64"
.\git-bash.exe -c "pacman -S --noconfirm gcc make automake autoconf m4 libtool flex bison gettext && git clone https://github.com/bats-core/bats-core.git && cd bats-core && ./install.sh /usr/local"
... followed by actual build steps, then tests.
Finally the full "C:\git-sdk-64" gets removed, so the next job must redo all this to avoid any remnants.
Dont know what testing a patch means in your case.
It means that the Git for Windows SDK is intended to develop Git for Windows. So when somebody reports a problem and somebody else comes up with a tentative patch, the Git for Windows SDK intends to make it easy for the reporter to verify that the patch fixes the reported problem.
While it might be convenient to use the Git for Windows SDK for anything else, those use cases are safely outside of what this overworked maintainer can reasonably support.
So when somebody reports a problem and somebody else comes up with a tentative patch, ...
can you point me to an example of that?
We use the above mentioned bats for pretty much that. The pipeline will look for all bats files and run them right after compiling. Only when it succeeded the maintainer will start looking at the code review. All the patch submitter has to do is ensure his problem is covered by bats file(s). The maintainer will of course start his review by looking for a change in some bats file first ...
So when somebody reports a problem and somebody else comes up with a tentative patch, ...
can you point me to an example of that?
Just search the issue list for "SDK".
We use the above mentioned bats for pretty much that.
You misunderstand. This is for things like testing the installer. Interactively. In git-for-windows/git#2779 (comment), for example, a contributor was able to test my suggestion (even if I messed it up).