Skip to content

Git status is triggering far too often on a large repo (during build) #231140

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jasonwilliams opened this issue Oct 11, 2024 · 5 comments · May be fixed by #246661
Open

Git status is triggering far too often on a large repo (during build) #231140

jasonwilliams opened this issue Oct 11, 2024 · 5 comments · May be fixed by #246661
Assignees
Labels
git GIT issues performance under-discussion Issue is under discussion for relevance, priority, approach
Milestone

Comments

@jasonwilliams
Copy link
Contributor

jasonwilliams commented Oct 11, 2024

Does this issue occur when all extensions are disabled?: N/A

  • VS Code Version: 1.94.2
  • OS Version: Windows 10

I noticed Git goes crazy whenever I build Chromium. It shouldn't be because I'm not running any Git-related tasks while this is happening, it takes up a lot of CPU. I noticed this older issue: #177773

I follow the same steps mentioned here and looked at the trace output.
It looks like every time the build generates a new file in the out directory it triggers the git extension to run git status again. I think I've managed to calm it down a bit by setting "git.autorefresh": false,, you can see the output below.

Output:

2024-10-11 19:35:37.122 [debug] [FileEventLogger][onWorkspaceWorkingTreeFileChange] C:\chromium\out\obj\third_party\blink\renderer\core\testing\sequence_test-bcfbf884.obj.tmp
2024-10-11 19:35:37.601 [trace] [Repository][onFileChange] Skip running git status because autorefresh setting is disabled.
2024-10-11 19:35:37.601 [debug] [FileEventLogger][onWorkspaceWorkingTreeFileChange] C:\chromium\out\obj\third_party\blink\renderer\core\testing\null_execution_context-fd483ba5.obj.tmp
2024-10-11 19:35:38.001 [trace] [Repository][onFileChange] Skip running git status because autorefresh setting is disabled.
2024-10-11 19:35:38.001 [debug] [FileEventLogger][onWorkspaceWorkingTreeFileChange] C:\chromium\out\obj\third_party\blink\renderer\core\core_hot\selector_query.obj
2024-10-11 19:35:38.001 [trace] [Repository][onFileChange] Skip running git status because autorefresh setting is disabled.
2024-10-11 19:35:38.001 [debug] [FileEventLogger][onWorkspaceWorkingTreeFileChange] C:\chromium\out\obj\third_party\blink\renderer\core\core_hot\selector_query-0130c7b5.obj.tmp
2024-10-11 19:35:38.635 [trace] [Repository][onFileChange] Skip running git status because autorefresh setting is disabled.
thousands more...

Despite it skipping this still looks like a bug, the out directory is in my gitignore so it shouldn't be doing anything on changes within this directory at all anyway. Should there be logic added to here to not trigger git commands if the file changes are in an ignored repository?

Using autorefresh false is a workaround to the problem but not a proper solution as I do want git to update when genuine files have changed. Maybe either the git extension should be fixed, or the built-in workspace watcher has a config to not watch ignored folders.

Steps to Reproduce:

  1. Load Chromium in VS Code
  2. Build Chromium
  3. Git activity goes super high in task manager (parent process being VS Code)
@lszomoru
Copy link
Member

You can also add the out folder to the watcher exclude list using the files.watcherExclude setting.

@lszomoru lszomoru added the under-discussion Issue is under discussion for relevance, priority, approach label Oct 21, 2024
@jasonwilliams
Copy link
Contributor Author

You can also add the out folder to the watcher exclude list using the files.watcherExclude setting.

Thanks @lszomoru

Do you know why VSCode still watches gitignored folders? Is this intentional? Or the logic wasn't added to ignore them. Even if the watching is required, having git fire "git status" on ignored folders is certainly a bug (due to there being no change).

It seems like this should be off by default, rather than developers needing to explicitly set this. It is also unnecessarily using a lot of resource when builds happen. This took me a while to figure out, so I'm sure other developers have fallen into this issue without knowing why it's happening.

@lszomoru
Copy link
Member

Looking at the code, there are two event listeners set up:

  1. workspace folder (except .git folder)
  2. .git folder

At the moment the workspace folder listener does not factor in the .gitignore file, but it probably should.

@lszomoru lszomoru added this to the Backlog milestone Dec 12, 2024
@BirdLogics
Copy link

On Linux, I had a similar issue. In my case, the operating system actually ran out of user watches due to the large number of files in the output build directory. The project was smaller, so I didn't notice any major build slowdowns, but the shortage of user watches did cause problems.

I was able to fix my issue by manually updating watcherExclude setting, but the problem would have been prevented in the first place if files in .gitignore were excluded from the watch.

@jasonwilliams
Copy link
Contributor Author

I've attempted to fix this here but ill need the help from a maintainer to explain why the glob patterns aren't matching up. it looks like this particular part of the code only accepts a single pattern so i can't do a coma-separated list of patterns here, and a grouping pattern won't work either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
git GIT issues performance under-discussion Issue is under discussion for relevance, priority, approach
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants