2

VSCodium version: 1.75.1, 1.76

Problem: switching to a different branch shows makes editor think that files were changed, but not commited.

There are no uncommited files/changes in my repository. Source control tab does not show any uncommited changes and git diff returns nothing. It's as if it's comparing the current branch to the one that I was on before opening the editor. Same happens if I switch the branch using git switch externally, from terminal.

The only way to "fix" this issue is to call a fill VSCode window reload, but if I switch to a different branch after that - the issue appears again. I tried creating a demo repo to show this issue, but it was not reproduced.

UPD1: here is what it looks like:

No changes in source control, diff still displaying

Before this I switched to a different branch (say from develop branch to a feature-1) and hit refresh on source control.

UPD2: VSCode git output from a repo that works fine

2023-03-05 17:02:53.265 [info] > git checkout -q lineageos-19.1 [796ms]
2023-03-05 17:02:53.273 [info] > git config --get commit.template [3ms]
2023-03-05 17:02:53.273 [info] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) refs/heads/lineageos-19.1 refs/remotes/lineageos-19.1 [1ms]
2023-03-05 17:02:53.397 [info] > git status -z -uall [121ms]
2023-03-05 17:02:54.496 [info] > git ls-files --stage -- /mnt/sdb2/Kernels/SAKE_Kernel/drivers/cpufreq/qcom-cpufreq-hw.c [4ms]
2023-03-05 17:02:54.502 [info] > git cat-file -s 98f9456f8697fa03731b9db72b22d264ea51219d [1ms]
2023-03-05 17:02:54.513 [info] > git show --textconv :drivers/cpufreq/qcom-cpufreq-hw.c [5ms]
2023-03-05 17:03:00.801 [info] > git for-each-ref --sort -committerdate --format %(refname) %(objectname) %(*objectname) [78ms]
2023-03-05 17:03:01.993 [info] > git checkout -q lineage-19.1-yaro [141ms]
2023-03-05 17:03:02.000 [info] > git config --get commit.template [3ms]
2023-03-05 17:03:02.004 [info] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) refs/heads/lineage-19.1-yaro refs/remotes/lineage-19.1-yaro [1ms]
2023-03-05 17:03:02.130 [info] > git status -z -uall [123ms]
2023-03-05 17:03:03.228 [info] > git ls-files --stage -- /mnt/sdb2/Kernels/SAKE_Kernel/drivers/cpufreq/qcom-cpufreq-hw.c [4ms]
2023-03-05 17:03:03.232 [info] > git cat-file -s 6a3f6cff159509b868f1ec14c97fc17fbaebdf86 [1ms]
2023-03-05 17:03:03.243 [info] > git show --textconv :drivers/cpufreq/qcom-cpufreq-hw.c [5ms]
2023-03-05 17:03:06.027 [info] > git check-ignore -v -z --stdin [27ms]
2023-03-05 17:03:11.230 [info] > git ls-files --stage -- /mnt/sdb2/Kernels/SAKE_Kernel/drivers/cpufreq/qcom-cpufreq-hw.c [5ms]
2023-03-05 17:03:11.236 [info] > git cat-file -s 6a3f6cff159509b868f1ec14c97fc17fbaebdf86 [1ms]
2023-03-05 17:03:11.251 [info] > git show --textconv :drivers/cpufreq/qcom-cpufreq-hw.c [5ms]
2023-03-05 17:03:11.675 [info] > git fetch [1637ms]
2023-03-05 17:03:11.683 [info] > git config --get commit.template [4ms]
2023-03-05 17:03:11.684 [info] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) refs/heads/lineage-19.1-yaro refs/remotes/lineage-19.1-yaro [1ms]
2023-03-05 17:03:11.801 [info] > git status -z -uall [113ms]
2023-03-05 17:03:12.740 [info] > git ls-files --stage -- /mnt/sdb2/Kernels/SAKE_Kernel/drivers/cpufreq/qcom-cpufreq-hw.c [4ms]
2023-03-05 17:03:12.744 [info] > git cat-file -s 6a3f6cff159509b868f1ec14c97fc17fbaebdf86 [1ms]
2023-03-05 17:03:12.755 [info] > git show --textconv :drivers/cpufreq/qcom-cpufreq-hw.c [5ms]

And here is from a broken one:

2023-03-05 15:57:40.780 [info] > git checkout -q <branch name> [220ms]
2023-03-05 15:57:40.789 [info] > git config --get commit.template [4ms]
2023-03-05 15:57:40.789 [info] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) refs/heads/<branch name> refs/remotes/<branch name> [1ms]
2023-03-05 15:57:40.795 [info] > git status -z -uall [2ms]

UPD3: I was able to narrow it down a little bit:

  1. The issue is reproduced only in repos where .git is a symlink to another folder (I am working in AOSP repos)
  2. Repos that do not have symlinks are not affected
  3. I finally learned that those bars are called git gutters
  4. Opened an issue in the official VSCode issue tracker: https://github.com/microsoft/vscode/issues/176497

UPD4: as a workaround I made the following script and added it to vscode's settings.json ("git.path": "/home/yaro/set-actual-git-dir"):

#!/bin/bash

git --git-dir="$(realpath .git/)" "${@}"

UPD5: git blame extension stopped working after the workaround from UPD4 so I had to update it:

#!/bin/bash

if [ -z "$VSCODE_GIT_COMMAND" ]; then
    git "${@}"
else
    git --git-dir="$(realpath .git/)" "${@}"
fi

Now it only sets --git-dir for VSCODE commands and not for extensions (at least not for git blame that I use: https://github.com/Sertion/vscode-gitblame/)

Yaro Slav
  • 23
  • 5
  • "_I tried creating a demo repo to show this issue, but it was not reproduced._", well, your _job_ as a question asker here is to help others reproduce the issue (see [mre] and [ask]). do update us if you find out how to reproduce it, and do continue trying to find out how to reproduce it. – starball Mar 02 '23 at 20:02
  • I will check if I can reproduce it in another larger repo. – Yaro Slav Mar 05 '23 at 14:01
  • I was able to find out what causes the issue, please see the upd3 in the op. – Yaro Slav Mar 08 '23 at 10:05
  • you have _symlink_ .git folders? I didn't know that was a thing. Why not just use git worktrees? – starball Mar 08 '23 at 17:09
  • Because that's how AOSP repositories work. – Yaro Slav Mar 08 '23 at 19:02

1 Answers1

1

Check first if you have a setting like git config --global core.autocrlf set to true.
It could transform EOL (end of lines) from LF to CRLF automatically at each branch switch.

You can check those attributes (before and after a switch) with git ls-files --eol.

If that is the issue, setting core.autocrlf to false is the recommended best practice.

The issue is reproduced only in repos where .git is a symlink to another folder (I am working in AOSP repos)

Yes, that was mentioned more generally before with "VS Code not to use the real path of a symlink" and "How do I get git changes to show in explorer in VS Code?"

You can try and open VSCode from a session where:

  • your working tree does not have a .git symlink (or a .git at all)
  • the environment variable GIT_DIR is set to the actual .git folder

That needs to be done before launching VSCode.
Or, as the OP did, modify the git call from VSCode settings.json:

"git.path": "/home/yaro/set-actual-git-dir"):

With set-actual-git-dir:

#!/bin/bash

git --git-dir="$(realpath .git/)" "${@}"

I finally learned that those bars are called git gutters

Gutter is the section beside the editor view in which you can have various indicators, including Git ones.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • But that would make the diff show up in git diff as well. In my case - it doesn't, it's just the UI that doesn't get updated. – Yaro Slav Mar 03 '23 at 15:25
  • @YaroSlav Can you share a screenshot which would illustrate "editor think that files were changed, but not commited."? – VonC Mar 03 '23 at 15:50
  • Yes, attached to the OP. – Yaro Slav Mar 04 '23 at 22:42
  • @YaroSlav When you click on the green bar in the gutter, do you see a "Git local working changes" green section with the change (moved or new lines in it)? – VonC Mar 04 '23 at 22:49
  • yes. I do see it – Yaro Slav Mar 05 '23 at 01:36
  • @YaroSlav And I suppose the issue persists with VSCode 1.76? Also, do you have any GIT_xxx environment variable? – VonC Mar 05 '23 at 01:39
  • correct, I've updated to 1.76 yesterday, the issue still persists. I don't see any GIT_ env variables set. – Yaro Slav Mar 05 '23 at 01:44
  • OK What OS are you on? (or, if on Windows, are you using WSL?) – VonC Mar 05 '23 at 01:45
  • Manjaro Linux, Gnome edition. – Yaro Slav Mar 05 '23 at 02:02
  • Both moving .git folder and exporting its actual path as GIT_DIR helped. – Yaro Slav Mar 08 '23 at 10:48
  • Sorry it looks like I spoke too soon, I created a task in vscode to automatically check if I'm in a git repo and set GIT_DIR to the realpath of .git folder, but that doesn't seem to work anymore. – Yaro Slav Mar 08 '23 at 11:10
  • @YaroSlav That would be my recommended workaround (pending the resolution of [issue 176497](https://github.com/microsoft/vscode/issues/176497)): use the actual absolute path of the .git in GIT_DIR, and launch VSCode. – VonC Mar 08 '23 at 11:13
  • @VolC after some more debugging it looks like I have to set the directory before launching vscodium. Unfortunate but oh well, hopefully vscode team will be able to fix it. – Yaro Slav Mar 08 '23 at 11:27
  • @YaroSlav Yes, that is what I meant: export GIT_DIR *before* launching VSCode. I have edited the answer to include your workaround. – VonC Mar 08 '23 at 12:43
  • edited the workaround a bit to be more reliable (no need to launch it from the terminal anymore). Please edit your comment once more and I will accept your answer. – Yaro Slav Mar 08 '23 at 14:32
  • @YaroSlav Well done. I have edited the answer accordingly. – VonC Mar 08 '23 at 15:30