'git clean -fdx' returns errorlevel 1

[talcloudshare]

Running 'git clean -fd' or 'git clean -fx' works properly (i.e., errorlevel is 0 at the end of the execution)

Seems to only happen with certain (large) repositories

[talcloudshare]

Before anyone asks, this does not happen with the linux Git cli

[dscho]

Before anyone asks, this does not happen with the linux Git cli

@talcloudshare that is not at all the first question I have... my first question is: are you absolutely sure you do not want to describe this issue in substantially more detail, including Git for Windows version, exact paste of the output of the command, URL to a repository with which this issue can be reproduced reliably?

[talcloudshare]

I am using the latest version of git for windows (2.6.2)

When running 'git clean -xfd' there's no output other than the removed folders/files, running 'echo %errorlevel%' returns 1

C:\code\cloudshare>git clean -xfd                                               
Removing ...                                         
...                                                
Removing ...                                           

C:\code\cloudshare>echo %errorlevel%                                            
1

Unfortunately the repository is private and cannot be shared, however I will attempt to debug this myself and try to narrow down the problem so that I can provide more information. Will be helpful if you could guide me, currently following https://github.com/git-for-windows/git/wiki/Debugging-Git

[kgybels]

@dscho I can reproduce if I create long paths:

KGybels@PC-KG MINGW64 /c/git/bug
$ ls
steps.sh*

KGybels@PC-KG MINGW64 /c/git/bug
$ cat steps.sh
#!/bin/bash
longname=$(printf '%*s' 100 | tr ' ' a)
git init test
cd test
mkdir -p $longname/$longname/$longname
touch $longname/test.txt
touch $longname/$longname/$longname/test.txt
git clean -xdf
echo $?
KGybels@PC-KG MINGW64 /c/git/bug
$ ./steps.sh
Initialized empty Git repository in C:/git/bug/test/.git/
Removing aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/test.txt
1

@talcloudshare Can you check for long paths in your case?

[kgybels]

@talcloudshare Enabling core.longpaths fixes it for my example.

Can you try with it enabled?
git config core.longpaths true

[talcloudshare]

Thanks, this works for me
Was suspicious of a long path that cannot be cleaned, but there was no indicative output