Re: Git clean enumerates ignored directories (since 2.27)

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Apr 14, 2021, 22:56 UTC
Message-ID: <YHdzDlAfsuZ21HR7@camp.crustytoothpaste.net>
In-Reply-To: <DM6PR00MB06829EC5B85E0C5AC595004E894E9@DM6PR00MB0682.namprd00.prod.outlook.com>

On 2021-04-14 at 17:17:46, Jason Gore wrote:

Show 7 quoted lines

> 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