Submodule update fails after GIT version 2.25.1 with Git Extensions

[ditard]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.32.0.windows.2
cpu: x86_64
built from commit: 3d45ac813c4adf97fe3733c1f763ab6617d5add5
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Windows 10 64-bit

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19042.1110]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Notepad++
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Core
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Git Extensions is used. This issue does not exist with GIT version 2.25.1!
According to Git Extensions team the problem is not in their side.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

submodule update --init --recursive

• What did you expect to occur after running these commands?

To update submodules.

• What actually happened instead?

Git Extensions console dump:

"C:\Program Files\Git\bin\git.exe" submodule update --init --recursive
Stack trace:
Frame        Function    Args
000FFFFA558  001800647D1 (000FFFFA778, 00000000002, 000FFFFCE00, 000FFFFDE50)

000FFFFA600  00180066C00 (00000000000, 000FFFFADB0, 000000002F8, 00000000000)

000FFFFAC80  0018014B818 (800000000000001C, 00000000000, 00000000000, 00000000000)
000FFFFAE50  001801761C9 (00000000000, 00000000000, 000512DDDFE, 000FFFFAEC0)

000FFFFAE90  0018021A31C (00000000001, 00300000003, 000006CE498, 00180236800)

000FFFFAEC0  0018021A796 (00051312C87, 000FFFFB0F0, 000FFFFB88C, 000006A7E10)

000FFFFAF70  001800DC33C (0000072A9F0, 00002E3A040, 000FFFFB0A0, 00000000001)

000FFFFAFC0  0018015030E (00800049AD0, 00000000020, 008000470A0, 00000000003)

000FFFFBCE0  001801517A1 (00000080000, 00010000000, 0010041BFBE, 0080004B8E0)

008000470A0  00180142EBB (00000080000, 00010000000, 0010041BFBE, 0080004B8E0)

008000470A0  0010041440F (0010000001F, 000FFFFBE90, 00180045D50, 00000000018)

00800049AD0  001004C1E4F (008FFFFFFFF, 000FFFFFFFF, 000FFFFFFFF, 00800049700)

00000000000  00100415650 (008000496D0, 000FFFFFFFF, 00000000000, 00800049700)

00000000000  00100416CAC (00180176251, 001005DAEF8, 000FFFFC420, 00800049700)

00000000000  0010045A0E8 (001004D1164, 00800000004, 001005D6318, 00000000001)

00000000000  0010042FB73 (001800DC264, 00180325C60, 001802AD38C, 00180236F60)

0080004BFC0  0010043484E (00000000005, 00180325C60, 00180236F60, 000FFFFC42C)

00000000000  00100435B40 (00000000000, FFFF000000000000, 00000000000, 00000000000)
5000001000000002  00100437626 (00000000001, 00000000001, 00000000000, 0080004C080)
5000001000000002  0010043777F (00000000040, 0080004B8A0, 00000000000, 00000000000)
5000001000000002  00100430B31 (00000000000, 00100437720, 0080004B940, 0080004B940)
00000000008  00100430FC1 (00000000080, 000FFFFC680, 7FF9E5CAE25F, 000FFFFC8F0)
001005D6558  001004393F6 (0000000001F, 00080000005, 00000000068, 00000000000)

0080004BF00  001004C11EC (000FFFFFFFF, 0080003A5F0, 001004CD548, 0080004B860)

00000000000  00100415650 (001004306B0, 00000000005, 0080004B880, 0080004B860)

000FFFFCA30  001004178E4 (0080003A100, 000FFFFCA30, 008000479A0, 001005DAEA8)

000FFFFCA30  00100401E1F (00000000002, 00000000001, 000FFFFC880, 00000000008)

000FFFFCA30  001004BFB92 (000FFFFCC10, 008000281A0, 00000000030, 00180325C00)

000FFFFCCE0  0018004B0FB (00000000000, 00000000000, 00000000000, 00000000000)

000FFFFCDA0  00180048A2A (00000000000, 00000000000, 00000000000, 00000000000)

000FFFFCE50  00180048AEC (00000000000, 00000000000, 00000000000, 00000000000)

End of stack trace
/mingw64/libexec/git-core/git-sh-setup: line 46: /git-sh-i18n: No such file or directory
Done

git-sh-i18n is not missing actually.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

** insert URL here **

[dscho]

Have you tried this without Git Extensions? With Git versions (and/or snapshots) in between? Did you come up with a minimal reproducible example?

[ditard]

Have you tried this without Git Extensions? - Yes. Submodule update works with Sourcetree or if I issue a command
git submodule update --init --recursive from a Git->GitBash.

With Git versions (and/or snapshots) in between?

I have tested GIT release versions for 2.26.2 to 2.32.0.2 with Git Extensions 3.4.3.9999 and reasults are;
v.2.26.2 - working
v.2.27.0, v.2.28.0, v.2.29.2.3 and v.2.30.1 - submodule update from Git Extensions hangs and do nothing (do not return stack trace from my initial comment).
v2.32.0.2 - submodule update from Git Extensions. Git Extensions console looks as the I show you in my initial comment.

You can find my minimal example here:
https://github.com/ditard/submoduleupdate_issue.git

It is a simple project repository without submodiles, but the behaviour of submodule update could be seen on it to.

[ditard]

And this is responce to me from Git Extensions teams.
gitextensions/gitextensions#9215

[ahumeniy]

Looking at the git-sh-setup file at line 46 it calls git-sh-i18n using the git --exec-path command to get the route where GIT is installed. When you run said command on GIT Bash you get an incorrect unix-style path:

C:/Program Files/Git/mingw64/libexec/git-core

instead of

/c/Program Files/Git/mingw64/libexec/git-core

This might be the source of the error. I tried to manually set the GIT_EXEC_PATH environment variable in a .bashrc file but it's not working.

[dscho]

Looking at the git-sh-setup file at line 46 it calls git-sh-i18n using the git --exec-path command to get the route where GIT is installed. When you run said command on GIT Bash you get an incorrect unix-style path:

C:/Program Files/Git/mingw64/libexec/git-core

instead of

/c/Program Files/Git/mingw64/libexec/git-core

Good point. However...

/mingw64/libexec/git-core/git-sh-setup: line 46: /git-sh-i18n: No such file or directory

It says /git-sh-i18n, not C:/Program Files/Git/mingw64/libexec/git-core/git-sh-i18n.

That suggests that https://github.com/git-for-windows/git/blob/v2.33.1.windows.1/git-sh-setup.sh#L47 fails to catch any output from git --exec-path. And the fact that there was a stack trace indicates that indeed, the command failed, rather badly. However, the stack trace was not accompanied by any indication as to whether it was caused by an "Access violation" or something else:

Stack trace:
[...]
End of stack trace

I vaguely remember having seen similar instances, though, and they were invariably due to anti-malware intercepting a call, claiming that bash.exe or git.exe did something fishy.

[dscho]

Oh, BTW...

me@work MINGW64 ~/repros/submodule-update-3356
$ git clone https://github.com/ditard/submoduleupdate_issue
Cloning into 'submoduleupdate_issue'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

me@work MINGW64 ~/repros/submodule-update-3356
$ cd submoduleupdate_issue/

me@work MINGW64 ~/repros/submodule-update-3356/submoduleupdate_issue (master)
$ git submodule update --init --recursive

me@work MINGW64 ~/repros/submodule-update-3356/submoduleupdate_issue (master)
$

In other words, it works as expected here. I cannot reproduce the reported issue.

[krptodr]

You will get a kick out of this.... The issue is with the font used in the editor when making the git-sh-setup file and how a human can't distinguish between the 1 and l (L), making it appear as 1 or l in the Courier New font -- to be specific.

In other words line 46 of the /mingw64/libexec/git-core/git-sh-setup file is saying:
. "$(git --exec-path)/git-sh-il8n"
------------------------------------^ (L)

instead of

. "$(git --exec-path)/git-sh-i18n"
------------------------------------^ (1)

[ahumeniy]

You will get a kick out of this.... The issue is with the font used in the editor when making the git-sh-setup file and how a human can't distinguish between the 1 and l (L), making it appear as 1 or l in the Courier New font -- to be specific.

In other words line 46 of the /mingw64/libexec/git-core/git-sh-setup file is saying: . "$(git --exec-path)/git-sh-il8n" ------------------------------------^ (L)

instead of

. "$(git --exec-path)/git-sh-i18n" ------------------------------------^ (1)

No. Mine looks fine, what version of the git-sh-setup file do you have?

[krptodr]

I'm using git version 2.32.0.windows.1

[dscho]

#3356 (comment) also has the correct file name, no il8n there.

[BasixKOR]

I was affected by this issue as well. I'm using an unsupported way (MSYS2 mixed) but I'll leave my error trace just in case if it helps.

C:/msys64/mingw64/libexec/git-core\git-submodule: line 22: .: git-sh-setup: file not found

[dscho]

I vaguely remember having seen similar instances, though, and they were invariably due to anti-malware intercepting a call, claiming that bash.exe or git.exe did something fishy.

I still suspect this.

[rimrul]

This has probably been fixed in Git for Windows 2.37.0, along with #3539.