Git clean now recurses into ignored and excluded directories in 2.27

[JasonGore]

• I was not able to find an open or closed issue matching what I'm seeing

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

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

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.

[JasonGore]

There's a corollary example that doesn't involve the exclude option.

If you also add directory30 to .gitignore with this example and simply do git clean -fdn, you will see long filename errors in git 2.27 that you don't see git 2.26. This will impact users that don't use the -e flag as well.

This is a problem for repos that have nested node_modules directories. They are generally ignored and cleaning previously wasn't an issue. However, now git 2.27 recurses into ignored directories generating a lot of long filename errors where it didn't previously.

[JasonGore]

This is still an issue with git 2.31.1. Git should not be enumerating ignored directories.

[dscho]

This is not a Windows-specific issue. Let's continue to discuss it on the Git mailing list (where you reported this issue also); It seems that @peff identified the culprit: https://lore.kernel.org/git/YHf%[email protected]/t/#u