Environment

• Git Extensions 33.33.33
• Build f94e62b (custom build up to date with master)
• Git 2.47.0.windows.1
• Microsoft Windows NT 10.0.26100.0
• .NET 9.0.6
• DPI 96dpi (no scaling)
• Portable: False
• Microsoft.WindowsDesktop.App Versions

    Microsoft.WindowsDesktop.App 8.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

    Microsoft.WindowsDesktop.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Issue description

On a relatively big repository, opening the file tree for the first time when the filetree is not filtered (and nothing is cached) could be really slow (on my work repo --that doesn't use git-lfs-- between 15 to 30s).

It 's the git grep --files-with-matches -z -e "^" a821940e23a71a770e51010a6e8939d3a447462f -- command which is long to run:

Note: it seems not to be only the number of files that is the cause of the command to be slow as my work repo has 3.1k files and as a comparison gitextensions repo has 2.8k...

Steps to reproduce

1. Open a big repository
2. Switch to file tree tab
3. notice that the display is slow

Did this work in previous version of GitExtensions?

Yes. Side effect of #12341

Diagnostics

Doing a git grep while there is nothing to search (takes between 15 to 30s) seems much less efficient than just loading the file tree with git ls-tree -r (less than 2.5s and cache seems more effective and could take only 0.15s).

I think it could be better to use git ls-tree -r instead of git grep when the file tree is not filtered