At first I thought #2715 covered my issue until I did more investigation and found the issue I'm encountering is specific to changes in git clean's -e behavior.
Setup
- Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
git version 2.27.0.windows.1
cpu: x86_64
built from commit: 907ab1011dce9112700498e034b974ba60f8b407
sizeof-long: 4
sizeof-size_t: 8
- 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 10.0.18363.900]
- 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:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
- Any other interesting things about your environment that might be related
to the issue you're seeing?
Not that I'm aware of. I have other users reporting this issue in our repo with git 2.27, as well.
Details
- Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
CMD
git init
longname="directory"
touch "$longname.txt"
for x in {1..30}; do
mkdir "$longname$x"
mv directory* "$longname$x"
done
git clean -ffdxn -e directory30
- What did you expect to occur after running these commands?
After running the repro above, git clean -ffdxn -e directory30 should run without showing long filename errors in that directory.
It does run without showing long filename errors in git version 2.26.2.windows.1:
D:\temp (master)
λ git clean -ffdxn -e directory30
D:\temp (master)
λ
- What actually happened instead?
As of git version 2.27.0.windows.1, using clean with exclude now generates long filename errors:
D:\temp (master)
λ git clean -ffdxn -e directory30
warning: could not open directory 'directory30/directory29/directory28/directory27/directory26/directory25/directory24/directory23/directory22/directory21/directory20/directory19/directory18/directory17/directory16/directory15/directory14/directory13/directory12/directory11/directory10/': Filename too long
D:\temp (master)
λ
- If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?
Repro covers the issue I think.
At first I thought #2715 covered my issue until I did more investigation and found the issue I'm encountering is specific to changes in git clean's
-ebehavior.Setup
defaults?
to the issue you're seeing?
Not that I'm aware of. I have other users reporting this issue in our repo with git 2.27, as well.
Details
CMD
Minimal, Complete, and Verifiable example
this will help us understand the issue.
After running the repro above,
git clean -ffdxn -e directory30should run without showing long filename errors in that directory.It does run without showing long filename errors in git version 2.26.2.windows.1:
As of git version 2.27.0.windows.1, using clean with exclude now generates long filename errors:
URL to that repository to help us with testing?
Repro covers the issue I think.