The stub created in this test is not restored after the test completes. This could cause test pollution if other tests rely on runGitCommand behavior. Consider wrapping the test in a try-finally block or using t.teardown() to restore the stub, similar to how it's done in other tests in this file (e.g., lines 393-394).

The stub runGitCommandStub is not restored after the test completes. Add a try-finally block or use t.teardown() to ensure the stub is restored, similar to how it's done in other tests in this file (e.g., lines 393-394).

Splitting on os.EOL will include an empty string at the end of the array if the git output ends with a newline (which is typical). This empty string will then be passed to git check-attr in getGeneratedFiles. Consider filtering out empty strings: return stdout.split(os.EOL).filter((line) => line.length > 0);

Missing JSDoc documentation. Consider adding a comment explaining what this function does, its parameters, and return value. For example: /**\n * Lists all files tracked by git in the given working directory.\n * @param workingDirectory The directory to list files in.\n * @returns An array of file paths relative to the working directory.\n */

Have you measured how long this operation takes overall on a large mono-repo?

I believe it should be relatively quick, since Git caches this information IIRC. That said, I haven't explicitly tested it on a large repo, but I can do that.

This could potentially be a very large number of files, too many to pass on the command line.

If we're mainly interested in CCR, could we filter down to just the diff here?

Alternatively, we could parse globs from the .gitattributes file rather than finding all files that match. That would be more likely to contain one entry for a large directory rather than potentially hundreds.

Or we could add a limit on the number of files on which we'll run check-attr.

This could potentially be a very large number of files, too many to pass on the command line.

True. The files could be passed in via stdin as well I think, which might be a more robust solution.

If we're mainly interested in CCR, could we filter down to just the diff here?

Potentially. We should first look at whether there is actually enough of a performance hit for large repos for this to make sense though.

Alternatively, we could parse globs from the .gitattributes file rather than finding all files that match. That would be more likely to contain one entry for a large directory rather than potentially hundreds.

I considered this, but I'd like to avoid it if we can get the information from git itself so we don't have to try and duplicate what it does.

Passing all files as command-line arguments via the spread operator could hit command-line length limits in repositories with very large numbers of files (e.g., tens of thousands). Consider using git check-attr --stdin instead, which reads file paths from stdin and avoids this limitation. This would involve piping the file list to git rather than passing it as arguments.

Splitting on os.EOL will include an empty string at the end of the array if the git output ends with a newline (which is typical). The regex won't match empty strings, but it's cleaner to filter them out explicitly: for (const result of stdout.split(os.EOL).filter((line) => line.length > 0)). This pattern is used elsewhere in the codebase (e.g., line 284 checks if (line) before processing).

Missing JSDoc documentation. Consider adding a comment explaining what this function does, its parameters, and return value. For example: /**\n * Returns a list of files marked as generated via the linguist-generated attribute in .gitattributes.\n * @param workingDirectory The directory to check for generated files.\n * @returns An array of file paths (relative to the working directory) that are marked as generated.\n */