How to install a specific git version using git sdk installer?

[webmaster33]

How can I install a specific git version using git sdk installer?
git-sdk-64-installer-1.0.0-rc-1.7z.exe

Currently installs:
$ git --version
git version 2.4.0.windows.1

But I need git v2.3.6 specific version.

Is it possible?
How?

[dscho]

How can I install a specific git version using git sdk installer?

You will have to use Git...

cd /usr/src/git
git checkout v2.3.6.windows.1
make install

[nalla]

Well.. actually you could skip that rebuilding by manually deprecating your mingw-w64-git package. Just download the version you want from the bintray repository here or here. Then run pacman -U path/to/package

[webmaster33]

Something went wrong with the install, there is no cloned git dir:

Reinitialized existing Git repository in C:/winprg/git-sdk-64/usr/src/MINGW-packages/.git/
fatal: remote origin already exists.
Reinitialized existing Git repository in C:/winprg/git-sdk-64/usr/src/MSYS2-packages/.git/
fatal: remote origin already exists.
Reinitialized existing Git repository in C:/winprg/git-sdk-64/usr/src/build-extra/.git/
fatal: remote origin already exists.
Cloning into 'git'...

w33@w33-PC MINGW64 /usr/src
$ ls
build-extra/  MINGW-packages/  MSYS2-packages/

w33@w33-PC MINGW64 /usr/src
$ ls -la
összesen 8
drwxr-xr-x 1 w33 None 0 máj.   5 11.43 ./
drwxr-xr-x 1 w33 None 0 máj.   5 11.29 ../
drwxr-xr-x 1 w33 None 0 máj.   5 11.31 build-extra/
drwxr-xr-x 1 w33 None 0 máj.   5 11.31 MINGW-packages/
drwxr-xr-x 1 w33 None 0 máj.   5 11.31 MSYS2-packages/

Strange...

UPDATE: I turned off Comodo Firewall, but still unsuccessful git clone.
I used the

git-sdk-installer-1.0.0-rc-3-64.7z.exe

and did set
C:\winprg\git-sdk-64
as install directory, all others were done automatically.

[dscho]

Reinitialized existing Git repository in C:/winprg/git-sdk-64/usr/src/MINGW-packages/.git/ fatal: remote origin already exists.

This means that you already have a Git SDK.

[webmaster33]

You suggested to build git from source to get the desired git version, but if there is no source how can I build it?

I have no other git sdk installed, I renamed all instances.

[linquize]

The installer automatically clones the necessary repositories and then build the HEAD revision of git.git. If you want to build a revision other than HEAD revision, you have to abort the build process, checkout the desired revision and build it yourself.
The source repositories are downloaded to C:\git-sdk-64\usr\src

[dscho]

I have no other git sdk installed, I renamed all instances.

Your earlier post suggests that there is still C:/winprg/git-sdk-64/usr/src/MINGW-packages/, i.e. there is a Git SDK at C:/winprg/git-sdk-64/.

[dscho]

In any case, you should be able to fix your particular Git SDK by calling

cd /usr/src/
git clone -c core.autocrlf=false https://github.com/git-for-windows/git
cd git
git checkout v2.3.6.windows.1
make install

[webmaster33]

@linquize:

The installer automatically clones the necessary repositories and then build the HEAD revision of git.git. If you want to build a revision other than HEAD revision, you have to abort the build process, checkout the desired revision and build it yourself.
The source repositories are downloaded to C:\git-sdk\usr\src

Wouldn't be logical to select which version you want to install?
It would be just a drop-down list option with the available tags.

@dscho: Anyway, thanks your help, I will do as you suggested, will do a git clone manually.

[webmaster33]

something is wrong with git clone :(

w33@w33-PC MINGW64 /c/winprg/git-sdk-64/usr/src
$ git clone -c core.autocrlf=false https://github.com/git-for-windows/git
Cloning into 'git'...

w33@w33-PC MINGW64 /c/winprg/git-sdk-64/usr/src
$ ls
build-extra/  MINGW-packages/  MSYS2-packages/

When debugging ssh:

w33@w33-PC MINGW64 /c/winprg/git-sdk-64/usr/src
$ ssh -vT https://github.com/git-for-windows/git                                OpenSSH_6.7p1, OpenSSL 1.0.2a 19 Mar 2015
debug1: Reading configuration data /etc/ssh/ssh_config
ssh: Could not resolve hostname https://github.com/git-for-windows/git: Name or service not known

[elieux]

This is an HTTPS URL, not an SSH one. Trying to connect to it with SSH doesn't make sense.

[elieux]

Try cloning with the command below. Does it show any errors?
GIT_TRACE=1 git clone -c core.autocrlf=false https://github.com/git-for-windows/git

[webmaster33]

I got this result, no errors:

w33@w33-PC MINGW64 /usr/src
$ GIT_TRACE=1 git clone -c core.autocrlf=false https://github.com/git-for-windows/git
18:23:56.440219 git.c:348               trace: built-in: git 'clone' '-c' 'core.autocrlf=false' 'https://github.com/git-for-windows/git'
Cloning into 'git'...
18:23:56.510223 run-command.c:347       trace: run_command: 'git-remote-https' 'origin' 'https://github.com/git-for-windows/git'

[webmaster33]

I also tried the following:

w33@w33-PC MINGW64 /usr/src
$ GIT_TRACE=1 ../../mingw64/libexec/git-core/git-remote-https.exe 'origin' 'https://github.com/git-for-windows/git'

w33@w33-PC MINGW64 /usr/src
$ ls
build-extra/  MINGW-packages/  MSYS2-packages/

No any output.

[dscho]

Wouldn't be logical to select which version you want to install?

No. The Git SDK is meant to develop Git for Windows, which means master.

[dscho]

w33@w33-PC MINGW64 /usr/src
$ GIT_TRACE=1 ../../mingw64/libexec/git-core/git-remote-https.exe 'origin' 'https://github.com/git-for-windows/git'

This looks like a bug to me which I have fixed already a long time ago, maybe reintroduced by downgrading Git. You might get lucky using CHARSET=cp1252 git clone ..., but it might be safer to use pacman -Syu to fix your Git version instead. But beware, if that wants to update your msys2-runtime, you will have to do that in a separate step, or from cmd.exe.

[webmaster33]

CHARSET=cp1252 git clone ... did not help :(

w33@w33-PC MINGW64 /usr/src
$ CHARSET=cp1252 git clone -c core.autocrlf=false https://github.com/git-for-win                                                                                                                                                                                               dows/git
Cloning into 'git'...

w33@w33-PC MINGW64 /usr/src
$ ls
build-extra/  MINGW-packages/  MSYS2-packages/

I updated with pacman -Syu, updated several things, like:
msys 125,9 KiB 1285K/s 00:00 [#####################] 100%
msys.sig 96,0 B 0,00B/s 00:00 [#####################] 100%
libtasn1-4.5-1-x86_64 90,7 KiB 731K/s 00:00 [#####################] 100%
libutil-linux-2.26.... 180,1 KiB 1209K/s 00:00 [#####################] 100%
util-linux-2.26.2-1... 1118,0 KiB 1448K/s 00:01 [#####################] 100%

But then again git clone, without success:

w33@w33-PC MINGW64 /usr/src
$ GIT_TRACE=2 git clone -c core.autocrlf=false https://github.com/git-for-window                                                                                                                                                                                               s/git
18:54:38.006551 git.c:348               trace: built-in: git 'clone' '-c' 'core.                                                                                                                                                                                               autocrlf=false' 'https://github.com/git-for-windows/git'
Cloning into 'git'...
18:54:38.072554 run-command.c:347       trace: run_command: 'git-remote-https' '                                                                                                                                                                                               origin' 'https://github.com/git-for-windows/git'

w33@w33-PC MINGW64 /usr/src
$ ls
build-extra/  MINGW-packages/  MSYS2-packages/

[elieux]

Can you try running the command from cmd? Sometimes the errors get swallowed in bash. You have to ditch the GIT_TRACE=1 part and set correct PATH or use absolute path to git.

[webmaster33]

@elieux: I got a pop-up dialog with error.
I try to translate it, but it will be not exact:
"The procedure entry point (SSL_CTX_set_alpn_protos) was not found in DLL (SSLEAY32.dll)."

Does it help?

[elieux]

That's definitely helpful. Can you clear your PATH to only include the git directory (and nothing else) and re-run the command?

[webmaster33]

Same error.

Used this:

c:\winprg\git-sdk-64\usr\src>set PATH=c:\winprg\git-sdk-64\cmd\

c:\winprg\git-sdk-64\usr\src>git clone -c core.autocrlf=false https://github.com/git-for-window
19:40:24.811659 git.c:348               trace: built-in: git 'clone' '-c' 'core.autocrlf=false' 'htt
ps://github.com/git-for-window'
Cloning into 'git-for-window'...
19:40:24.870662 run-command.c:347       trace: run_command: 'git-remote-https' 'origin' 'https://git
hub.com/git-for-window'

Same error for this path:
set PATH=c:\winprg\git-sdk-64\mingw64\bin\

[elieux]

I suggest one (or more) of the following steps:

• reboot and check if the issue remains
• uninstall GfW and nuke any remaining files, install again and check if the issue remains
• start procmon, reset filter, add filter Process Name=git-remote-https.exe (don't forget to press Add) and re-run the command; then look at the log to see what ssleay32.dll it's loading (or save the log as PML and upload it somewhere for us)

[webmaster33]

I will try these tomorrow.
I hope one of them will help.

[webmaster33]

- reboot and check if the issue remains

Rebooted, same error happens.

uninstall GfW and nuke any remaining files, install again and check if the issue remains

Same error happened.

I debugged with procmon, and I found, that installer uses the ssleay32.dll from folder c:\Windows\System32. There were an ssleay32.dll v1.0.1.8 size 353280 bytes.
The ssleay32.dll file in c:\winprg\git-sdk-64\mingw64\bin\ is newer, v1.0.2.1.

So I copied:

c:\winprg\git-sdk-64\mingw64\bin\ssleay32.dll
c:\winprg\git-sdk-64\mingw64\bin\libeay32.dll
to
c:\Windows\System32\

This was the cause of the bug, now

git clone -c core.autocrlf=false https://github.com/git-for-windows/git

was executed well, the git dir appeared in usr/src.

I think, the installer should detect, that there are
ssleay32.dll
libeay32.dll
existing files in c:\Windows\System32
so ask if user allows installer to overwrite them.

This way this bug could be fixed.

[elieux]

so ask if user allows installer to overwrite them.

Reasonable installers won't ever dump open-source DLLs into Windows directories, precisely because it causes conflicts with other software. There are other factors at play here, not only the version number. I wouldn't object if the installer displayed a warning message about possible DLL conflicts.

the installer should detect

Unfortunately, there are so many DLLs that can cause problems (not only these two) that I'm not sure if it's worth the work.

I'm currently thinking of something along the lines of making a list of all DLLs in mingw??/bin and usr/bin and trying to find them in PATH. I'm not sure if the concept is sound. @dscho, what do you think?

[dscho]

I'm currently thinking of something along the lines of making a list of all DLLs in mingw??/bin and usr/bin and trying to find them in PATH. I'm not sure if the concept is sound. @dscho, what do you think?

According to the official documentation, the .dll search order is:

1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

(This is when SafeDllSearchMode is enabled, the default in Windows Vista and later; for XP, the default is off, in which case the current directory is moved from 5. to 2.)

So I think it is safe to assume that we cannot fix it, because we cannot move the system directory after the PATH, and we should refrain from copying all of the .dll files from /mingw??/bin/ to /mingw??/libexec/git-core/ (although we could hard-link them, I guess, iff the file system lets us do that, and that is still only a solution for the installer, not for portable Git).

[webmaster33]

Still I don't understand, why Windows 7 system32 directory was searched before it looked the /bin directory.

[dscho]

Still I don't understand, why Windows 7 system32 directory was searched before it looked the /bin directory.

Please re-read my comment, in particular this part:

According to the official documentation, the .dll search order is:

1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

and then notice that git-remote-https.exe is not in the /mingw64/bin/ directory, therefore 1. above does not manage to find the .dll. Therefore, Windows goes on to look at 2.: the system directory. I believe this answers your (implicit) question.

And please also note that I do not like at all that the discussion in this (already addressed) ticket was forced to revolve around some completely different problem. Anybody who has the same problem will have trouble finding this discussion and the corresponding resolution.

I want every new problem to be reported in a separate ticket.