Since version 2.10.1, can't push/pull/fetch using 'Git Gui' when the remote path contains non-ASCII characters

[morningt]

• [v] 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.10.1.windows.1
64-bit

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

$ cmd.exe /c ver
Microsoft Windows [Version 6.1.7601]
64-bit

• 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
Path Option: Cmd
SSH Option: OpenSSH
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled

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

It works fine until version 2.10.0.
But, since version 2.10.1, 'Git Gui' and other GUI client tools can't push/pull/fetch.
(Tested under Git Gui, Git Extensions, TortoiseGit, SourceTree)

And 'bash' works fine for all versions. : )

Details

• 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.

1. Create remote repository at "D:/Repo/■sample2" or "//Repo/■sample2". 
2. Register above remote repository as 'remote2'.
3. Run 'Git Gui' and then select sub-menu [remote -> fetch from -> 'remote2'] 
    to fetch from remote repository named as 'remote2'. 

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

Git Gui returns 'Success' message on the green line.

• What actually happened instead?

Git Gui returns 'Error: Command Failed' message on the red line, with belows.

"git-upload-pack 'D:/Repo/�sample2.git'": git-upload-pack 'D:/Repo/�sample2.git': No such file or directory
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

[PhilipOakley]

See the other closed issues on this and similar (you need the 'is open' part removed from the search box ;-)

Click on the code tab (next to the issues tab) then (after update) on the 'releases' (third one in after commits / branches / rele...).

Then fire up https://github.com/git-for-windows/git/releases/tag/v2.11.1.windows-prerelease.2 which should solve this. This will be incorporated in the next formal release when upstream completes its current cycle/sprint.

[morningt]

@PhilipOakley Thank you for your quick reply.
However, I have already tried most other versions, including v2.11.1.windows-prelease.2, before posting this issue. And I tried searching with 'is:issue non ascii' and/or other keywords, but I could not find an issue with the same symptom. :'-(
Is there any other solution I can try ?

P.S. Additionally, I attach the files below.
[Bash works always]

[v2.10.1.windows.1 ~ v2.11.1.windows-prelease.2]


(skip Git Extensions, SourceTree images)

[~v2.10.0.windows.1]

[PhilipOakley]

Hi, thanks for doing the checking. This more sounds like a character encoding argument between the various different systems which all try to be 'smart' about encoding. the Git Gui is written in Tcl/Tk and is said to be unicode aware, but it looks like the three way transfer (config -> gui -> git) includes an extra conversion that a two step direct bash version (config -> git) does not have.

Are you able to capture the actual charater codes shown on screen?

Also can you try seeing if the gui can open the repo from a non-repo directory (e.g. cd /usr/src then git gui), which should list recent repos the gui has opened (stored in the --global .gitcofig file), and also let you browse to the repo directory.

If you browse to a repo with the non-ascii char (It is unicode isn't it??) then try opening it you should see a new entry in the .gitconfig (see the hex for git's view of the encoding), and then see if it actually opens it.

Alternatively, delve into the gui code to find the remote access code, and extend the command to give the CURL_VERBOSE and TRACE options (maybe even directed to a file), just to get some guidance on when the faulty char conversion happens.

See #1014 (the final few comments) for some points on running the patched gui from the command line

[YueLinHo]

@morningt Does adding a env. var. LC_ALL=C work for you?

[morningt]

@YueLinHo Yes, it works with cmd.exe

[morningt]

@PhilipOakley

Are you able to capture the actual charater codes shown on screen?

This is my example Unicode character. (Windows 'Start' button -> type 'charmap' in the search box)

Also can you try seeing if the gui can open the repo from a non-repo directory ......

$ git config --global -l
~~~
gui.recentrepo=D:/Sources/sample2
gui.recentrepo=D:/Sources/■sample2

Is this right action you requested ? ( Sorry, I'm not an expert... :-) )
'Git Gui' opens well even if the local path contains non-ascii char.
Maybe the local path doesn't matter.

[YueLinHo]

@dscho Suppose this is a duplicate of #945.

[PhilipOakley]

From: Yue Lin Ho @dscho Suppose this is a duplicate of #945.

I'm not so sure. The current pre-release is said not fix the issue (If I read the reports correctly). It looks to me like it is a three way interaction with the GUI internal coding when accessing the remote's details. I could be wrong. It sounds like the user's Language env var can be part of the issue. dunno. Philip

[slo617]

It looks to me like it is a three way interaction with the GUI internal coding when accessing the remote's details.

I do not think this issue is caused by the GUI. This issue also happens when git.exe is called from command line (cmd.exe)

Are you able to capture the actual charater codes shown on screen?

In my case, I have problems with letters like "äöü".
In Unicode and ISO-8859-15 these letters are encoded as 0xC4, 0xF6 and 0xFC
In codepage 437 and 850 these letters are encoded as 0x84, 0x94 and 0x82.

I have installed 2.11.1.prerelease.2 and tested from command line (cmd.exe) and with Git Extensions. In both cases it does not work out of the box, but it does work after setting LC_ALL=C.
(As mentioned before, running /mingw64/bin/git from within "git bash" is always working...)

C:\Users\user>"C:\Program Files\Git\bin\git.exe" --version
git version 2.11.1.windows.prerelease.2

C:\Users\user>"C:\Program Files\Git\bin\git.exe" clone "C:/Users/user/git/test/pub-äöü-test/rep.git" "C:/Users/user/git/test/rep"
Cloning into 'C:/Users/user/git/test/rep'...
"git-upload-pack 'C:/Users/user/git/test/pub-äöü-test/rep.git'": git-upload-pack 'C:/Users/user/git/test/pub-äöü-test/rep.git': No such file or directory
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

C:\Users\user>set LC_ALL=C

C:\Users\user>"C:\Program Files\Git\bin\git.exe" clone "C:/Users/user/git/test/pub-äöü-test/rep.git" "C:/Users/user/git/test/rep"
Cloning into 'C:/Users/user/git/test/rep'...
done.

C:\Users\user>

[slo617]

I hope this helps to narrow the problem:
v2.11.0.windows.1 seems to work quite fine (at least for this issue) while v2.11.0.windows.2 does not work anymore.