vscode: Git Explorer Color Highlight on git diffs does not "refresh" on changes, only highlights on start / restart

Does this issue occur when all extensions are disabled?: Yes

  • VS Code Version:
Version: 1.63.2
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-15T09:37:28.172Z (1 wk ago)
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.6.0
  • OS Version: MacOS Big Sur 11.6

Steps to Reproduce:

  1. Make a change in on any files that is inside a Git Repository
  2. I don’t see the yellow M, or highlight on the Explorer
  3. If I reload VSCode, I now do see the yellow M image
  4. Similarly, if I delete the change I just made, the yellow M remains, indicating a diff in git (but there isn’t)
  5. If I reload VSCode, it goes away.

Seems like refresh on Explorer is broken, not the Git Diff part, since this feature (the blue bar indicating change in line in file) works perfectly image

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 16 (3 by maintainers)

Most upvoted comments

@kukdh1, thank you very much for sharing all these details. The git decorators are being updated through various events, one being the file system events scoped to the .git folder of the folder/workspace. I have just got to the bottom of a similar issue so I was wondering if you could try the following:

  1. Could you please check your user/workspace setting and share the values of the files.watcherExclude.
  2. Could you please invoke the Git: Set Log Level... command to set the log level to Trace
  3. Reproduce the remaining issue, and send me the contents of the Git output channel which you can access by invoking the Git: Show Output Log... command

I can happily confirm that I had this in my settings.json for some god awful reason.

    "files.watcherExclude": {
        "**": true
    }

Really not sure where it came from, maybe an extension in the past messed it up(?) Does running VSCode without extensions not reset settings.json(?). But after removing it, the feature works as expected (as it always have for years).

I am closing the issue.

Hey, I’m running into the same issue. Here is a video. I’m using VS Code 1.64.2 on a MacBook Pro (2021, M1 Pro) and macOS Monterey 12.2.

Recording 2022-02-25 at 13 56 21

I think you can close the issue (I cannot do that as I’m not an author of this issue), as my issues are solved. Thank you very much for your help.

For anybody who has same issues:

  1. Try to reinstall VSCode (to remove potential garbage files caused by automatic update).
  2. Reset files.watcherExclude setting to the default.

@lszomoru As I noticed that the files.watcherExclude includes whole git directory, I tried with default one by clicking Reset Setting in Settings window:

"files.watcherExclude": {
  "**/.git/objects/**": true,
  "**/.git/subtree-cache/**": true,
  "**/node_modules/*/**": true,
  "**/.hg/store/**": true
}

And I validated that the git highlights are updated correctly (as shown in below, on 1.65.2): Recording 2022-03-26 at 05 46 54 Also, Stage Selected Ranges works well: Recording 2022-03-26 at 05 50 46

Here is the git logs after stage, and last two lines are added:

[2022-03-25T20:54:52.496Z] git.stage 1
[2022-03-25T20:54:52.496Z] git.stage.scmResources 1
[2022-03-25T20:54:52.526Z] > git add -A -- D:\git\test\README.md [25ms]
[2022-03-25T20:54:52.585Z] > git symbolic-ref --short HEAD [24ms]
[2022-03-25T20:54:52.589Z] [debug] [.git] Change: d:\git\test\.git\index
[2022-03-25T20:54:52.615Z] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track) refs/heads/master refs/remotes/master [28ms]
[2022-03-25T20:54:52.642Z] > git remote --verbose [24ms]
[2022-03-25T20:54:52.642Z] > git for-each-ref --sort -committerdate --format %(refname) %(objectname) %(*objectname) [26ms]
[2022-03-25T20:54:52.669Z] > git config --get commit.template [24ms]
++++ [2022-03-25T20:54:53.737Z] > git ls-files --stage -- D:\git\test\README.md [25ms]
++++ [2022-03-25T20:54:53.762Z] > git cat-file -s 3b95c160030f12fd6dfc138e9e1dff143fa1a357 [23ms]