fix: secret scan pre-commit crashing on big merges

[salome-voltz]

Context

ggshield secret scan pre-commit crashes on Windows when committing a merge with many long file names with [WinError 206] The filename or extension is too long.
This happens because ggshield is building a git command that is longer than the maximum path length on Windows. (see #1032 ).

What has been done

Functions that execute git commands on all files in a merge were updated to process files in batches, respecting the limit defined by MAX_FILES_PER_GIT_COMMAND.

Validation

On Windows:

• Runs the script provided in the issue description. ggshield should crash
• Test with the updated ggshield version. ggshield should proceed as expected.

PR check list

• As much as possible, the changes include tests (unit and/or functional)
• If the changes affect the end user (new feature, behavior change, bug fix) then the PR has a changelog entry (see doc/dev/getting-started.md). If the changes do not affect the end user, then the skip-changelog label has been added to the PR.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.76%. Comparing base (28f5153) to head (4af42f9).
Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1048      +/-   ##
==========================================
- Coverage   92.10%   91.76%   -0.34%     
==========================================
  Files         181      143      -38     
  Lines        7762     6048    -1714     
==========================================
- Hits         7149     5550    -1599     
+ Misses        613      498     -115     

Flag	Coverage Δ
unittests	91.76% <100.00%> (-0.34%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sevbch]

It's looking good to me!

As our CI is running tests in Windows environment, is it possible to design a test which would crash before and now pass? Or are there blockers for such a test?

[salome-voltz]

I added a test that crashed on Windows before the change and passes now. The test is a bit slow, however, as it generates a lot of files, and I can't use cassettes to speed it up so I don't know if we want to keep it. WDYT @sevbch ?

[sevbch]

I added a test that crashed on Windows before the change and passes now. The test is a bit slow, however, as it generates a lot of files, and I can't use cassettes to speed it up so I don't know if we want to keep it. WDYT @sevbch ?

I tried locally launching your test and it took 0.2s. It's indeed a bit slow for a unit test but it seems acceptable to me. I'd rather keep the test to prevent us from future regressions.