Various things are broken when the install path has spaces

[kevin-david]

Edit: As stated below, I had Git installed in C:\Program Files (x86)\Git (the default recommended by the installer) which seems to have caused this issue. git rebase -m was the first thing I noticed.

Repro:

kedavid@KEDAVID-DEV [D:\work\git1] [feature]
> git lg
* 5c2d42d - (HEAD, master, feature) second commit commit (44 seconds ago) <Kevin David>
* 1a5b550 - first commit (52 seconds ago) <Kevin David>

kedavid@KEDAVID-DEV [D:\work\git1] [feature]
> git checkout master
Switched to branch 'master'

kedavid@KEDAVID-DEV [D:\work\git1] [master]
> git checkout -B feature 1a5b550
Switched to and reset branch 'feature'

kedavid@KEDAVID-DEV [D:\work\git1] [feature]
> testcommit feature commit
[feature 8128af2] feature commit commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 feature commit

kedavid@KEDAVID-DEV [D:\work\git1] [feature]
> git rebase -m master
First, rewinding head to replay your work on top of it...
git: 'Files' is not a git command. See 'git --help'.

Did you mean this?
        ls-files

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

testcommit creates a dummy commit and echos the arguments into a file with the same name (e.g. echo "feature commit" >> "feature commit"), so no magic there.

Running the developer's preview release.

[kevin-david]

Rebase (without -m) also seems to be busted if you hit conflicts, with a similar error:

kedavid@KEDAVID-DEV [<branch>]
> git rebase 083e4df
First, rewinding head to replay your work on top of it...
Applying: <commit msg>
Using index info to reconstruct a base tree...
<snip>
warning: 4 lines add whitespace errors.
Falling back to patching base and 3-way merge...
git: 'Files' is not a git command. See 'git --help'.

Did you mean this?
        ls-files
Failed to merge in the changes.
Patch failed at 0001 <commit msg>
The copy of the patch that failed is found in:
   D:/.../.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

[nalla]

Workaround should be: install git into a non spaced directory.

[kevin-david]

Yep, that did it. Capital "Files" should have given it away. Thanks for the quick workaround! I edited the issue to better reflect the actual problem.

[dscho]

Heh, when I called it developers' preview, I was actually hoping for testers who can fix the problems and open PRs ;-)

[dscho]

@kevin-david could you run the problematic commands again, after setting GIT_TRACE=1? I am not sure whether the problems are with Git or with the MSys2 runtime and would like you to find out.

[kevin-david]

Here's the GIT_TRACE output of the same repro I described earlier:

PS C:\Users\Kevin\Desktop\test1> git rebase -m master
20:39:05.832814 git.c:557               trace: exec: 'git-rebase' '-m' 'master'
20:39:05.832814 run-command.c:351       trace: run_command: 'git-rebase' '-m' 'master'
20:39:05.873122 git.c:348               trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '-m' 'master'
20:39:05.916233 git.c:348               trace: built-in: git 'rev-parse' '--git-dir'
20:39:05.943682 git.c:348               trace: built-in: git 'rev-parse' '--is-bare-repository'
20:39:05.962695 git.c:348               trace: built-in: git 'rev-parse' '--show-toplevel'
20:39:05.988651 git.c:348               trace: built-in: git 'config' '--bool' 'rebase.stat'
20:39:06.012395 git.c:348               trace: built-in: git 'config' '--bool' 'rebase.autostash'
20:39:06.033208 git.c:348               trace: built-in: git 'config' '--bool' 'rebase.autosquash'
20:39:06.058251 git.c:348               trace: built-in: git 'rev-parse' '--verify' 'master^0'
20:39:06.084275 git.c:348               trace: built-in: git 'rev-parse' '--verify' 'master^0'
20:39:06.106162 git.c:348               trace: built-in: git 'symbolic-ref' '-q' 'HEAD'
20:39:06.134927 git.c:348               trace: built-in: git 'rev-parse' '--verify' 'HEAD'
20:39:06.159635 git.c:348               trace: built-in: git 'rev-parse' '--verify' 'HEAD'
20:39:06.179647 git.c:348               trace: built-in: git 'update-index' '-q' '--ignore-submodules' '--refresh'
20:39:06.200320 git.c:348               trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules'
20:39:06.219387 git.c:348               trace: built-in: git 'diff-index' '--cached' '--quiet' '--ignore-submodules' 'HEAD' '--'
20:39:06.240424 git.c:348               trace: built-in: git 'merge-base' 'ad0b9eedb6a93754a542b34d1ac559b2fb10e2c1' '50e9a8e01fa86eabacdaeed28888a9caf1c4c3cb'
First, rewinding head to replay your work on top of it...
20:39:06.277373 git.c:348               trace: built-in: git 'checkout' '-q' 'ad0b9eedb6a93754a542b34d1ac559b2fb10e2c1^0'
20:39:06.307815 git.c:348               trace: built-in: git 'update-ref' 'ORIG_HEAD' '50e9a8e01fa86eabacdaeed28888a9caf1c4c3cb'
20:39:06.348281 git.c:348               trace: built-in: git 'rev-list' '--reverse' '--no-merges' 'ad0b9eedb6a93754a542b34d1ac559b2fb10e2c1..50e9a8e01fa86eabacdaeed28888a9caf1c4c3cb'
20:39:06.390318 git.c:348               trace: built-in: git 'rev-parse' '--verify' 'HEAD'
20:39:06.440310 git.c:557               trace: exec: 'git-Files' '(x86)\Git\mingw64\libexec\git-core\git.exe' 'merge-recursive' '50e9a8e01fa86eabacdaeed28888a9caf1c4c3cb^' '--' 'ad0b9eedb6a93754a542b34d1ac559b2fb10e2c1' '50e9a8e01fa86eabacdaeed28888a9caf1c4c3cb'
20:39:06.440310 run-command.c:351       trace: run_command: 'git-Files' '(x86)\Git\mingw64\libexec\git-core\git.exe' 'merge-recursive' '50e9a8e01fa86eabacdaeed28888a9caf1c4c3cb^' '--' 'ad0b9eedb6a93754a542b34d1ac559b2fb10e2c1' '50e9a8e01fa86eabacdaeed28888a9caf1c4c3cb'
git: 'Files' is not a git command. See 'git --help'.

Did you mean this?
        ls-files
20:39:06.482253 git.c:348               trace: built-in: git 'rerere'

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

I won't commit to fixing this... but if I get some time tomorrow I'll see if I can get a development environment set up :)

[dscho]

I'll see if I can get a development environment set up

You should, because it just might be the case that b072d68 fixed this already, without your noticing. You can test by installing the SDK, then initializing the local build-extra clone:

cd /usr/src/build-extra
git fetch origin
git checkout master

(this needs to be done only once, after that a simple git pull will update it), and then building your own portable release:

/usr/src/build-extra/portable/release.sh kevin-david-test

[kevin-david]

No dice, at least from what I can tell. I got a different error but it looks like it was because the portable installer defaulted to C:\Program Files\ rather than C:\Program Files (x86)\... when I switched it back I ended up with the same error as before.

[dscho]

@kevin-david my suspicion is that the command-line rewriting in the Git wrapper may still be flawed. Could you recompile the git-wrapper.exe in your SDK with the -g flag (and without the -O2 flag), then overwrite C:\Program Files (x86)\mingw32\libexec\git-core\git-rev-parse.exe with a copy of it and then single-step through this loop to figure out what is going on?

The easiest way to recompile with debug information (read: -g) is something like this:

$ cd /usr/src/git
$ touch compat/win32/git-wrapper.c
$ make V=1 git-wrapper.exe
$ <copy-edit the two `gcc` calls that compile compat/win32/git-wrapper.o` and link
 `git-wrapper.exe`, respectively, removing all `-O2` flags and adding `-g` flags as necessary>

The gdb session to single-step through the loop should be as simple as

$ gdb /c/Program\ Files\ \(x86\)/mingw32/libexec/git-core/git-rev-parse.exe
[...]
> b git-wrapper.c:147
> r
[...]

and then single-stepping with u and inspecting the variables with p <variable name>.

Since gdb has no native support for printing UTF-16 strings, it might be necessary to edit the git-wrapper.c source and insert debug print statements such as fwprintf(stderr, L"p: %s\n", p);, recompile, re-copy and re-run.

Thanks for your efforts!