On 2021-04-14 at 17:17:46, Jason Gore wrote:
> I'm unsure of whether this issue is Windows-specific but at the very least I suspect this is a change of behavior that would affect all platforms.
> 
> In July 2020 I reported an issue I initially encountered in 2.27 that still seems to be present in 2.31.1.windows.1: https://github.com/git-for-windows/git/issues/2732
> 
> Since I haven't seen a response on the issue and it still occurs I decided to email this list as well.
> 
> Package managers such as PNPM tend to create very long filenames due to symlinking. Having git not enumerate these ignored directories is essential to leveraging any sort of clean behavior (both for performance and for warning output) as we did before version 2.27. Our repo clean functions went from taking a few seconds to over 10 minutes due to this change in behavior.

It looks like there were some changes to the dir.c code between 2.26 and
2.27 which may have impacted clean.  I'm CCing Elijah Newren who wrote
those patches and in any event would be more familiar with that code
than I am.

I've taken the liberty of pulling in your testcase from that issue and
converting it to work in POSIX sh on a Linux machine.  If the path is
not sufficiently long for your needs, you can bump the value of the variable
"last" below.

----
#!/bin/sh

git init test-repo
cd test-repo
longname="directory"
touch "$longname.txt"
last=400
for x in $(seq 1 $last); do
  mkdir "x$longname$x"
  mv directory* "x$longname$x"
  mv "x$longname$x" "$longname$x"
done
git clean -ffdxn -e directory$last
----

When it fails, it will complain that it wasn't able to open the
directory.  It still exits zero, however.

I haven't bisected this, so I don't know if those patches are related to
the problem or not.  I'm a little short on time today to investigate
further, but hopefully this can get someone on the right path with a
modified version and git bisect run if nothing else.

> I've also had repeated problems sending you this email as your email server seems to reject any email with a URL in it (per the github link above.)

I don't think that's the problem, since this email came through just
fine.  It's more likely that your email was being bounced for HTML,
which isn't allowed on the list.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US