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

morningt · 2017-01-21T04:54:24Z

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

The text was updated successfully, but these errors were encountered:

PhilipOakley · 2017-01-21T11:04:03Z

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 · 2017-01-21T15:40:44Z

@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 · 2017-01-21T20:54:53Z

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 · 2017-01-23T02:02:25Z

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

morningt · 2017-01-23T15:03:48Z

@YueLinHo Yes, it works with cmd.exe

morningt · 2017-01-23T16:37:12Z

@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 · 2017-01-24T02:31:47Z

@dscho Suppose this is a duplicate of #945.

PhilipOakley · 2017-01-24T10:46:21Z

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 · 2017-01-24T13:58:40Z

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 · 2017-01-27T09:47:45Z

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.

A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls for POSIX-1.2008, 2016-07-20). An unintended side-effect is that "cold-calling" into the POSIX emulation will start with a locale based on the current code page, something that Git for Windows is very ill-prepared for, as it expects to be able to pass a command-line containing non-ASCII characters to the shell without having those characters munged. One symptom of this behavior: when `git clone` or `git fetch` shell out to call `git-upload-pack` with a path that contains non-ASCII characters, the shell tried to interpret the entire command-line (including command-line parameters) as executable path, which obviously must fail. This fixes #1036 Signed-off-by: Johannes Schindelin <[email protected]>

Git [can clone again](git-for-windows/git#1036) from paths containing non-ASCII characters. Signed-off-by: Johannes Schindelin <[email protected]>

dscho · 2017-02-21T21:08:52Z

@slo617 thanks for the reproducer. The problem was apparently introduced by the jump from Cygwin 2.4.1 -> 2.6.0 as part of Git for Windows' updated components in v2.10.1.

A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls for POSIX-1.2008, 2016-07-20). An unintended side-effect is that "cold-calling" into the POSIX emulation will start with a locale based on the current code page, something that Git for Windows is very ill-prepared for, as it expects to be able to pass a command-line containing non-ASCII characters to the shell without having those characters munged. One symptom of this behavior: when `git clone` or `git fetch` shell out to call `git-upload-pack` with a path that contains non-ASCII characters, the shell tried to interpret the entire command-line (including command-line parameters) as executable path, which obviously must fail. This fixes #1036 Signed-off-by: Johannes Schindelin <[email protected]>

YueLinHo · 2017-03-01T02:50:04Z

Confirmed that this issue is solved while using GfW 2.12.0. :-)

A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls for POSIX-1.2008, 2016-07-20). An unintended side-effect is that "cold-calling" into the POSIX emulation will start with a locale based on the current code page, something that Git for Windows is very ill-prepared for, as it expects to be able to pass a command-line containing non-ASCII characters to the shell without having those characters munged. One symptom of this behavior: when `git clone` or `git fetch` shell out to call `git-upload-pack` with a path that contains non-ASCII characters, the shell tried to interpret the entire command-line (including command-line parameters) as executable path, which obviously must fail. This fixes #1036 Signed-off-by: Johannes Schindelin <[email protected]>

A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls for POSIX-1.2008, 2016-07-20). An unintended side-effect is that "cold-calling" into the POSIX emulation will start with a locale based on the current code page, something that Git for Windows is very ill-prepared for, as it expects to be able to pass a command-line containing non-ASCII characters to the shell without having those characters munged. One symptom of this behavior: when `git clone` or `git fetch` shell out to call `git-upload-pack` with a path that contains non-ASCII characters, the shell tried to interpret the entire command-line (including command-line parameters) as executable path, which obviously must fail. This fixes git-for-windows#1036 Signed-off-by: Johannes Schindelin <[email protected]>

A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls for POSIX-1.2008, 2016-07-20). An unintended side-effect is that "cold-calling" into the POSIX emulation will start with a locale based on the current code page, something that Git for Windows is very ill-prepared for, as it expects to be able to pass a command-line containing non-ASCII characters to the shell without having those characters munged. One symptom of this behavior: when `git clone` or `git fetch` shell out to call `git-upload-pack` with a path that contains non-ASCII characters, the shell tried to interpret the entire command-line (including command-line parameters) as executable path, which obviously must fail. This fixes #1036 Signed-off-by: Johannes Schindelin <[email protected]>

A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls for POSIX-1.2008, 2016-07-20). An unintended side-effect is that "cold-calling" into the POSIX emulation will start with a locale based on the current code page, something that Git for Windows is very ill-prepared for, as it expects to be able to pass a command-line containing non-ASCII characters to the shell without having those characters munged. One symptom of this behavior: when `git clone` or `git fetch` shell out to call `git-upload-pack` with a path that contains non-ASCII characters, the shell tried to interpret the entire command-line (including command-line parameters) as executable path, which obviously must fail. This fixes git-for-windows#1036 Signed-off-by: Johannes Schindelin <[email protected]>

A change between versions 2.4.1 and 2.6.0 of the MSYS2 runtime modified how Cygwin's runtime (and hence Git for Windows' MSYS2 runtime derivative) handles locales: d16a56306d (Consolidate wctomb/mbtowc calls for POSIX-1.2008, 2016-07-20). An unintended side-effect is that "cold-calling" into the POSIX emulation will start with a locale based on the current code page, something that Git for Windows is very ill-prepared for, as it expects to be able to pass a command-line containing non-ASCII characters to the shell without having those characters munged. One symptom of this behavior: when `git clone` or `git fetch` shell out to call `git-upload-pack` with a path that contains non-ASCII characters, the shell tried to interpret the entire command-line (including command-line parameters) as executable path, which obviously must fail. This fixes #1036 Signed-off-by: Johannes Schindelin <[email protected]>

YueLinHo mentioned this issue Jan 23, 2017

Can't access remote repository if the URL contains Chinese word #945

Closed

dscho closed this as completed in git-for-windows/MINGW-packages@c7a8a9a Feb 21, 2017

dscho added a commit to git-for-windows/build-extra that referenced this issue Feb 21, 2017

Mention Bug Fix in release notes

d4e6ca3

Git [can clone again](git-for-windows/git#1036) from paths containing non-ASCII characters. Signed-off-by: Johannes Schindelin <[email protected]>

dscho added this to the v2.11.2 milestone Feb 21, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

morningt commented Jan 21, 2017 •

edited

Loading

PhilipOakley commented Jan 21, 2017

morningt commented Jan 21, 2017

PhilipOakley commented Jan 21, 2017

YueLinHo commented Jan 23, 2017 •

edited

Loading

morningt commented Jan 23, 2017

morningt commented Jan 23, 2017

YueLinHo commented Jan 24, 2017

PhilipOakley commented Jan 24, 2017 via email

slo617 commented Jan 24, 2017

slo617 commented Jan 27, 2017 •

edited

Loading

dscho commented Feb 21, 2017

YueLinHo commented Mar 1, 2017

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

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

Comments

morningt commented Jan 21, 2017 • edited Loading

Setup

Details

PhilipOakley commented Jan 21, 2017

morningt commented Jan 21, 2017

PhilipOakley commented Jan 21, 2017

YueLinHo commented Jan 23, 2017 • edited Loading

morningt commented Jan 23, 2017

morningt commented Jan 23, 2017

YueLinHo commented Jan 24, 2017

PhilipOakley commented Jan 24, 2017 via email

slo617 commented Jan 24, 2017

slo617 commented Jan 27, 2017 • edited Loading

dscho commented Feb 21, 2017

YueLinHo commented Mar 1, 2017

morningt commented Jan 21, 2017 •

edited

Loading

YueLinHo commented Jan 23, 2017 •

edited

Loading

slo617 commented Jan 27, 2017 •

edited

Loading