Git - large change improvements

[lszomoru]

• Add telemetry for when the git.statusLimit is reached
• Improve experience when the git.statusLimit is reached (guide user to increase the limit)

[digitarald]

Hey @lszomoru, reviving this based on our recent discussion and the extension hang data.

There are 3 major ways to hit this limit (maybe others? tell me):

1. Accidental .git: .git was initialized in some parent folder (like ~/ in "Unable to watch for file changes in this large workspace folder" #151827) by accident.
2. Repos with huge build/dependency folders that should be ignored. VS Code helps with that by recommending to detect and ignore those folders.
3. Merges or initializing large repos. The users most affected by this warning and who need to change the limit.

Lower value: vscode.git already causes hangs for some users (https://github.com/microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Agit+label%3Aperf), so a lower value could help users with accidental git repos. Large repo users can still change the setting.
Higher limit: Assumes most of the users that get the limit actually have intentional large repos. Most that hit the limit seem to be just slightly over 10.000 – so even just using 11.000 would remove 99% of hangs.

Other ideas:

• 💡 Make the limit time-based. Compared to the number of files changed, the amount of time a status update takes is much closer to the impact on user experience. It also adapts to the environment, as we see issues from users with extremely slow git setups (firewall, antivirus, spinny disks, etc).
• Prevent interruption by only warning users that actually ever opened SCM view during the session, otherwise silently disable file change updates and only show a warning in SCM.
• Link to setting from the warning (right now just offers OK and Never show again).

cc @jrieken

[lszomoru]

@digitarald, thank you very much for the write-up.

I would personally prefer to increase the limit so that people with large repositories do not see the warning and they can use VS Code to interact with their large repository but also try to limit the number of repositories that are being opened "accidentally".

Accidental .git: .git was initialized in some parent folder (like ~/ in #151827) by accident.

As far as my understanding goes, the standard behaviour of git.exe is to start walking up the directory tree in order to discover the first .git folder. One can control this behaviour by using the GIT_CEILING_DIRECTORIES environment variable. The most common scenario here is when there is a .git folder in the $HOME directory and that is the one that gets opened. Couple of things we can consider:

1. Do not open the .git folder from $HOME unless $HOME is opened in VS Code.
2. Show a notification that the .git folder is in the $HOME folder and have the user agree to open it.