joaomoreno
commented
4 years ago Can you show me the full output of Git: Show Git Output?
Open rohansekhri opened 4 years ago
joaomoreno
commented
4 years ago Can you show me the full output of Git: Show Git Output?
rohansekhri
commented
4 years ago Here is the git output (replaced by project name with some_folder):
git show :Orchestrator/ORC_Tools/lib/ssh_base.rb
git ls-files --stage -- C:\_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb
git show :Orchestrator/ORC_Tools/lib/ssh_base.rb
git ls-files --stage -- C:\_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb
git status -z -u
git symbolic-ref --short HEAD
git rev-parse virt_image
git rev-parse --symbolic-full-name virt_image@{u}
git rev-list --left-right virt_image...refs/remotes/origin/virt_image
git for-each-ref --format %(refname) %(objectname)
git remote --verbose
git config --get commit.template
<--- this is where i opened it again by right clicking and ....--->
git show :orchestrator/orc_tools/lib/ssh_base.rb
git ls-files --stage -- C:\_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb
git cat-file -s 176f53d0ac43a2e16010a658a6a67f0ed08569d2I guess I figured out the issue:
This is due to Windows's ignore case. If one looks at the first few lines, one can see the path in Caps. At this point of time, the file is opened from the Explorer View (as per gitlens, the file is not tracked). If one makes a change now, it shows up in Source Control and this tab has the correct (all lower case) path and when someone opens it from there, the tracking is fixed and git gutters and GitLens work fine.
I have tried git config --global core.ignorecase true, but that too did not help.
This not only needs to be fixed from a repository end, I believe this should be fixed in VSCode too, where Windows ignores case and does a merge on the folder and thus, git losing all the tracking.
joaomoreno
commented
4 years ago What Git version do you have? The latest 2.25 has known Windows casing issues: https://github.com/git-for-windows/git/issues/2499 https://github.com/git-for-windows/git/issues/2478
We already have a casing fix in the insider release, can you give that a try?
rohansekhri
commented
4 years ago Yes. This is reproducible on
Version: 1.43.0-insider (system setup) Commit: 595f98455be0aac7372a0ae7841efae9b91b848e Date: 2020-02-18T13:52:42.988Z Electron: 7.1.11 Chrome: 78.0.3904.130 Node.js: 12.8.1 V8: 7.8.279.23-electron.0 OS: Windows_NT x64 10.0.18362
I downgraded to 2.24 and that version too has the same issue.
$ git config --list
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=false
core.fscache=true
core.symlinks=true
core.editor="C:\\Program Files\\Microsoft VS Code\\Code.exe" --wait
credential.helper=manager
color.ui=auto
user.name=Rohan Sekhri
user.email=xxxxx@xxx.com
mergetool.sourcetree.cmd=''
mergetool.sourcetree.trustexitcode=true
core.ignorecase=true
~
$ git --version
git version 2.24.0.windows.2Could you maybe show me the entire Git Output after opening that folder?
rohansekhri
commented
4 years ago Here is the git output from Insiders (used it since you mentioned it has a fix related to casing)
Open repository: c:\_repos\some_folder
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse virt_image
> git rev-parse --symbolic-full-name virt_image@{u}
> git rev-list --left-right virt_image...refs/remotes/origin/virt_image
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git check-ignore -v -z --stdin
> git config --get commit.template
> git check-ignore -v -z --stdin
> git show :Orchestrator/ORC_Tools/lib/ssh_base.rb
> git ls-files --stage -- C:\_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse virt_image
> git rev-parse --symbolic-full-name virt_image@{u}
> git rev-list --left-right virt_image...refs/remotes/origin/virt_image
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git config --get commit.template
> git check-ignore -v -z --stdin
> git show :orchestrator/orc_tools/lib/ssh_base.rb
> git ls-files --stage -- C:\_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb
> git cat-file -s 176f53d0ac43a2e16010a658a6a67f0ed08569d2
> git check-ignore -v -z --stdin
GitLens output:
[2020-02-19 14:29:38:435] [1] GitService.initialize
[2020-02-19 14:29:38:435] [2] GitService.getBuiltInGitApi
[2020-02-19 14:29:38:572] [2] GitService.getBuiltInGitApi completed • 136 ms
[2020-02-19 14:29:38:673] Git found: 2.24.0.windows.2 @ C:\Program Files\Git\cmd\git.exe • 101 ms
[2020-02-19 14:29:38:673] [1] GitService.initialize completed • 238 ms
[2020-02-19 14:29:38:676] Starting repository search in 1 folders
[2020-02-19 14:29:38:676] [3] GitService.repositorySearch(c:\_repos\some_folder) searching (depth=1)...
[2020-02-19 14:29:38:690] [6] LineAnnotationController.resume
[2020-02-19 14:29:38:691] [6] LineAnnotationController.resume completed • 0 ms
[2020-02-19 14:29:38:715] GitLens (v10.2.1) activated • 282 ms
[2020-02-19 14:29:38:716] [c] GitService.getRepository
[2020-02-19 14:29:38:779] [c:\_repos\some_folder] git rev-parse --show-toplevel • 102 ms
[2020-02-19 14:29:38:780] [3] GitService.repositorySearch(c:\_repos\some_folder) found root repository in 'c:/_repos/some_folder'
[2020-02-19 14:29:38:789] [3] GitService.repositorySearch(c:\_repos\some_folder) returned 1 repositories (c:/_repos/some_folder) • 112 ms
[2020-02-19 14:29:38:912] [c:/_repos/some_folder] git remote -v • 105 ms
[2020-02-19 14:29:38:926] [c] GitService.getRepository returned undefined • 210 ms
[2020-02-19 14:29:38:927] [1d] GitService.isTracked returned false • 0 ms
[2020-02-19 14:29:56:860] [23] GitService.getRepoPath
[2020-02-19 14:29:56:860] [24] GitService.getRepository
[2020-02-19 14:29:56:960] [c:/_repos/some_folder] git ls-files -- Orchestrator/ORC_Tools/lib/ssh_base.rb • 97 ms
[2020-02-19 14:29:56:960] [29] GitService.isTracked returned false • 98 ms
[2020-02-19 14:29:56:960] [24] GitService.getRepository returned undefined • 99 ms
[2020-02-19 14:29:57:055] [c:\_repos\some_folder\Orchestrator\ORC_Tools\lib] git rev-parse --show-toplevel • 95 ms
[2020-02-19 14:29:57:056] [23] GitService.getRepoPath returned c:/_repos/some_folder • 196 ms
[2020-02-19 14:29:57:056] [2b] GitService.getRepository
[2020-02-19 14:29:57:056] [2b] GitService.getRepository returned c:/_repos/some_folder • 0 ms
[2020-02-19 14:29:57:145] [c:/_repos/some_folder] git ls-files -- c:\_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb • 88 ms
[2020-02-19 14:29:57:146] [2c] GitService.isTracked returned false • 89 ms
[2020-02-19 14:30:05:092] [44] GitService.isTracked returned false • 0 ms
[2020-02-19 14:30:11:326] [5d] GitService.getRepoPath
[2020-02-19 14:30:11:326] [5e] GitService.getRepository
[2020-02-19 14:30:11:426] [c:/_repos/some_folder] git ls-files -- orchestrator/orc_tools/lib/ssh_base.rb • 99 ms
[2020-02-19 14:30:11:427] [5f] GitService.isTracked returned true • 100 ms
[2020-02-19 14:30:11:427] [5e] GitService.getRepository returned c:/_repos/some_folder • 101 ms
[2020-02-19 14:30:11:427] [5d] GitService.getRepoPath returned c:/_repos/some_folder • 101 ms
[2020-02-19 14:30:11:427] [60] GitService.getRepository
[2020-02-19 14:30:11:428] [60] GitService.getRepository returned c:/_repos/some_folder • 0 ms
[2020-02-19 14:30:11:516] [c:/_repos/some_folder] git ls-files -- c:\_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb • 88 ms
[2020-02-19 14:30:11:516] [61] GitService.isTracked returned true • 88 ms
[2020-02-19 14:30:11:538] [62] GitService.getBlameForFile
[2020-02-19 14:30:11:540] [63] GitService.isTracked returned true • 0 ms
[2020-02-19 14:30:11:584] [64] GitService.getBlameForLine
[2020-02-19 14:30:11:584] [65] GitService.getBlameForFile
[2020-02-19 14:30:11:722] [c:/_repos/some_folder] git blame --root --incremental -- orchestrator/orc_tools/lib/ssh_base.rb • 181 ms
[2020-02-19 14:30:11:722] [66] GitService.getCurrentUser
[2020-02-19 14:30:11:811] [c:/_repos/some_folder] git config --get-regex user.(name|email) • 88 ms
[2020-02-19 14:30:11:893] [c:/_repos/some_folder] git check-mailmap Rohan Sekhri <email@is_hidden.com> • 81 ms
[2020-02-19 14:30:11:894] [66] GitService.getCurrentUser completed • 171 ms
[2020-02-19 14:30:11:897] [62] GitService.getBlameForFile completed • 358 ms
[2020-02-19 14:30:11:897] [65] GitService.getBlameForFile completed • 312 ms
[2020-02-19 14:30:11:898] [64] GitService.getBlameForLine completed • 314 ms
[2020-02-19 14:30:12:164] [6d] GitService.getBlameForRangeSync
[2020-02-19 14:30:12:164] [6d] GitService.getBlameForRangeSync completed • 0 ms
[2020-02-19 14:30:15:088] [72] GitService.getBlameForLine
[2020-02-19 14:30:15:088] [73] GitService.getBlameForFile
[2020-02-19 14:30:15:088] [73] GitService.getBlameForFile completed • 0 ms
[2020-02-19 14:30:15:088] [72] GitService.getBlameForLine completed • 0 ms
[2020-02-19 14:30:16:889] [7c] GitService.getBlameForLine
[2020-02-19 14:30:16:889] [7d] GitService.getBlameForFile
[2020-02-19 14:30:16:890] [7d] GitService.getBlameForFile completed • 0 ms
[2020-02-19 14:30:16:890] [7c] GitService.getBlameForLine completed • 0 ms
[2020-02-19 14:30:17:709] [82] GitService.getCommitForFile
[2020-02-19 14:30:17:709] [83] GitService.getLogForFile
[2020-02-19 14:30:17:711] [84] GitService.getDiffForLine
[2020-02-19 14:30:17:711] [85] GitService.getDiffForFile
[2020-02-19 14:30:17:802] [c:/_repos/some_folder] git ls-files -- orchestrator/orc_tools/lib/ssh_base.rb • 90 ms
[2020-02-19 14:30:17:802] [86] GitService.isTracked returned true • 90 ms
[2020-02-19 14:30:17:820] [c:/_repos/some_folder] git show -M --format= --minimal -U0 30ae25d9238778919145133cee8761be583204e2 -- orchestrator/orc_tools/lib/ssh_base.rb • 95 ms
[2020-02-19 14:30:17:821] [85] GitService.getDiffForFile completed • 109 ms
[2020-02-19 14:30:17:822] [84] GitService.getDiffForLine completed • 110 ms
[2020-02-19 14:30:18:070] [c:/_repos/some_folder] git log --format=%x3c%x2ff%x3e%n%x3cr%x3e%x20%H%n%x3ca%x3e%x20%aN%n%x3ce%x3e%x20%aE%n%x3cd%x3e%x20%at%n%x3cc%x3e%x20%ct%n%x3cp%x3e%x20%P%n%x3cs%x3e%n%B%n%x3c%x2fs%x3e%n%x3cf%x3e -n2 --follow --numstat --summary 30ae25d9238778919145133cee8761be583204e2 -- orchestrator/orc_tools/lib/ssh_base.rb • 266 ms
[2020-02-19 14:30:18:070] [89] GitService.getCurrentUser
[2020-02-19 14:30:18:070] [89] GitService.getCurrentUser completed • 0 ms
[2020-02-19 14:30:18:073] [83] GitService.getLogForFile completed • 364 ms
[2020-02-19 14:30:18:073] [82] GitService.getCommitForFile completed • 364 ms
[2020-02-19 14:30:18:073] [8b] GitService.getRemotes
[2020-02-19 14:30:18:074] [8c] GitService.getRepository
[2020-02-19 14:30:18:074] [8c] GitService.getRepository returned c:/_repos/some_folder • 0 ms
[2020-02-19 14:30:18:074] [8b] GitService.getRemotes completed • 0 msAnother piece of information: I added a file under orchestrator/orc_tools/lib/foo_folder and it is being tracked as expected.
joaomoreno
commented
4 years ago You can omit GitLens output from now on, it's a separate extension.
It looks like everything is working, from the output.
Another piece of information: I added a file under orchestrator/orc_tools/lib/foo_folder and it is being tracked as expected.
So... there are paths which work, and others which don't? Can you try to distill what the rule is?
rohansekhri
commented
4 years ago Already done that in my previous comment:
Paths with: C:\_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb work and paths with C:\_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb don't (note the capital O's in the second one). If one opens the file from File Explorer, the latter path is taken and if one opens from the Source Control tab in VSCode, the former is taken, which is correct.
Take a look at the git bash output below. It seems to be ignoring the case in path:
** MINGW64 /c/_repos/gfx_ip_val/Orchestrator/ORC_Tools (virt_image)** --> paths have capital Os
$ git status
On branch virt_image
Your branch is up to date with 'origin/virt_image'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: **../../orchestrator/orc_tools/lib/ssh_base.rb** --> path has lowercase 'o'
VSCode is treating them as different paths, else i would see just one instance of the file. The one on the right in the image below is tracked.
Hope all this helps. :)
joaomoreno
commented
4 years ago Can you show me the very first lines of the git output, which show which git.exe Code is using?
rohansekhri
commented
4 years ago Looking for git in: C:\Program Files\Git\cmd\git.exe Using git 2.24.0.windows.2 from C:\Program Files\Git\cmd\git.exe git rev-parse --show-toplevel git rev-parse --git-dir Open repository: c:\xxxxxxxxxx git fetch git status -z -u git symbolic-ref --short HEAD
I downgraded from 2.25 based on your feedback
calemonte
commented
4 years ago I'm having the same exact issue as described in this ticket. I'm running version 1.43.0 on a Darwin x64 19.2.0 OS connected to a remote server using the Remote-SSH extension. I can only see the gutters after I've saved a change and then right-clicked to open the file from the Source Control panel. I installed insiders and the problem was still there. Let me know if you need any other info.
pbanaszkiewicz
commented
4 years ago I'm having a similar issue (git changes not discovered in file explorer and not shown in editor gutter). I was able to narrow it down to VSC expanding symlink in project path:
/home/piotr/workspace/project (and .git is here too)workspace is a symlink to /mnt/c/Users/Piotr/workspace for my convenience/home/piotr/workspace/project/mnt/c/Users/Piotr/workspace)
Show Git output for the file opened as /home/piotr/workspace/project/file.py:
Looking for git in: git
Using git 2.17.1 from git
> git rev-parse --show-toplevel
> git rev-parse --git-dir
Open repository: /mnt/c/Users/Piotr/workspace/carpentries/amy
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse rqjob-status
> git rev-parse --symbolic-full-name rqjob-status@{u}
fatal: no upstream configured for branch 'rqjob-status'
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git config --get commit.template
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git check-ignore -v -z --stdin
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git show HEAD:amy/autoemails/actions.py
> git ls-tree -l HEAD -- /mnt/c/Users/Piotr/workspace/carpentries/amy/amy/autoemails/actions.py
> git check-ignore -v -z --stdin
> git show :amy/autoemails/actions.py
> git ls-files --stage -- /mnt/c/Users/Piotr/workspace/carpentries/amy/amy/autoemails/actions.py
> git cat-file -s 2f1adf95480301bc03d56ec6e0ac97f250a4f4a2
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git show :amy/autoemails/actions.py
> git ls-files --stage -- /mnt/c/Users/Piotr/workspace/carpentries/amy/amy/autoemails/actions.py
> git cat-file -s 2f1adf95480301bc03d56ec6e0ac97f250a4f4a2
> git rev-parse --show-toplevelFor now my workaround is to use the longer project path when opening it in VSC.
JacobDB
commented
4 years ago Seeing the exact same thing with symlinks in WSL, super annoying. Glad I found this, though so I can at least work around it. Whipped up a script that mitigates the issue for the time being...
[ old, dumb code removed ]Pretty sure this will only work for opening stuff, so if you use the CLI for other things, this script could be made a bit more robust to support all the flags and stuff. Personally I just use it to open things 😅
EDIT: Could this possibly be implemented as the real fix? Simply expanding the path with readlink?
JacobDB
commented
4 years ago Quick update, just whipped up a more robust script that should retain support for all arguments. I'm not great at writing bash scripts, so this may be a bit fragile, and may not cover all use cases, but everything seems to work in my testing.
# Modify VS Code CLI to expand symlinks before opening, to fix git status highlighting
code() {
# Set the path to VS Code
code_path="/mnt/c/Users/Jacob/AppData/Local/Programs/Microsoft VS Code/bin/code";
# Store converted arguments
converted=""
# Loop through all passed arguments
for arg in "$@"
do
# Retain line and colum number information
pattern="([^:]*)((:[0-9]+)+)?";
[[ $arg =~ $pattern ]]
prefix=${BASH_REMATCH[1]}
suffix=${BASH_REMATCH[2]}
if [[ -d $prefix ]] || [[ -f $prefix ]]
then
# Expand paths, resolving symlinks
converted="$converted $(readlink -f $prefix)$suffix"
else
# Retain non-path arguments
converted="$converted $arg"
fi
done
# Reconstruct the command
"$code_path" $converted
}Gist; https://gist.github.com/JacobDB/572f980e23ba11b5479e3df94a01a220
sstoychev
commented
3 years ago I confirm this is related to symlinks. Long story short - our projects were in /var/www/html, we run out of space and we moved them to /data making html symlink to /data/var/www/html:
$ ls -l /var/www/
total 0
lrwxrwxrwx 1 root root 19 Oct 6 09:37 html -> /data/var/www/html/I can even open the same file two times - once from Explorer, once from Source Control. Note that the breadcumbs are different too.
These screenshots are from the current stable version: Version: 1.51.1 Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f Date: 2020-11-10T23:31:29.624Z Electron: 9.3.3 Chrome: 83.0.4103.122 Node.js: 12.14.1 V8: 8.3.110.13-electron.0 OS: Linux x64 5.9.3-1-MANJARO snap
but it is the same on Insiders and on Linux(Manjaro) and Windows 10 working with remote-ssh to the linux machien. I also tried disabling extensions if it matters.
Thanks to this ticket I simply reopened the projects from the path without symlink and everything works.
dseynhae
commented
3 years ago Confirming the issue: When
When Opening VSCode on a FOLDER, then the gutters are always present:
My environment: $ lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 7.6 (Maipo) Release: 7.6 Codename: Maipo
$ code --version 1.51.0 fcac248b077b55bae4ba5bab613fd6e9156c2f0c x64
So the "workaround" of starting in the logical path versus physical path doesn't seem to apply in my case...
EDIT:
The way I capture my workspace folder location in my settings seems to matter:
If I use the physical path name (no symbolic links), everything works.
If I use the logical path name (with symbolic links), the gutter annotations don't work when opening the file from the explorer pane....
DrShushen
commented
3 years ago Can confirm, experiencing this issue when the repo that I open is in a symlink path. When opening the repo through the "real" path, the git gutters work normally.
JoenZhu
commented
2 years ago any updates, have the same issue
rohansekhri
commented
2 years ago @lszomoru and @joaomoreno any update on this one? It's almost 2 years since I opened this. Thank you
lszomoru
commented
2 years ago @rohansekhri, based on your message I am assuming that you are still able to reproduce the same behaviour with the latest version of VS Code and with the latest version of Git for Windows. I have tried to distill the history of this issue which as you say it's 2 years old and I see that this issue has gone into various directions with various configurations.
Paths with: C:_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb work and paths with C:_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb don't (note the capital O's in the second one). If one opens the file from File Explorer, the latter path is taken and if one opens from the Source Control tab in VSCode, the former is taken, which is correct.
Are still seeing paths with different casing for a resource in "Explorer" and the "Source Control" view? How do you open the folder/workspace? Are you using the Terminal, or launching VS Code and then opening the folder/workspace.
Another piece of information: I added a file under orchestrator/orc_tools/lib/foo_folder and it is being tracked as expected.
Are you sill able to add a file in a folder and see that is being tracked as expected?
Could you also try the following and share the contents of the git output channel:
--disable-extensions flag and open your folder/workspaceGit: Set Log Level... command and set the level to Tracefiles.watcherExclude setting.
realjjaveweb
commented
2 years ago I have very similar issue and I noticed one thing:
There is a different path used for opening files from "Explorer" and opening files from "Source control".
It also causes that I can actually open same file twice which can cause further sync/save bugs (I am NOT talking about split screen).
The difference:
When file is opened from VSCODE Explorer - it shows relative path in header (doesn't show gutters):
src > modulepath > somefile.ext ... (src/modulepath/somefile.ext shown on tab)
X
When file is opened from Source control - it shows absolute path in header (shows gutters):
home > myuser > pathtoproject > src > modulepath > somefile.ext ...
The path shown on tab is ~/pathtoproject/src/modulepath/somefile.ext.
So clearly there are 2 bugs:
I am still having this issue in the latest version 1.66.1
lszomoru
commented
2 years ago @realjjaveweb, thanks for the additional information. Couple of questions:
code folder), or the "File -> Open Folder" menu?Git: Show Git Output commandrealjjaveweb
commented
2 years ago @realjjaveweb, thanks for the additional information. Couple of questions:
- Do you have any symbolic links on the path of the path that you are opening in VS Code?
- How do you open the folder/workspace? Are you using the cli (ex:
code folder), or the "File -> Open Folder" menu?- When you open a folder/workspace, could you please share the git output that you can access with the
Git: Show Git Outputcommand
@lszomoru
code folder it opens the folder as a whole new project = asks whether to trust authors again and no lastly opened files are there - however - then the problem is not there and the file paths in headers are always relative (in BOTH cases Explorer and Source Control) [2022-04-11T18:46:30.142Z] Validating found git in: git
[2022-04-11T18:46:30.180Z] Using git from git
[2022-04-11T18:46:30.280Z] > git rev-parse --git-dir [29ms]
[2022-04-11T18:46:30.284Z] Open repository: /home/myuser/pathtoproject
[2022-04-11T18:46:30.678Z] > git symbolic-ref --short HEAD [45ms]
[2022-04-11T18:46:30.730Z] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track) refs/heads/master refs/remotes/master [24ms]
[2022-04-11T18:46:30.794Z] > git remote --verbose [5ms]
[2022-04-11T18:46:30.795Z] > git for-each-ref --sort -committerdate --format %(refname) %(objectname) %(*objectname) [42ms]
[2022-04-11T18:46:30.970Z] > git config --get commit.template [115ms]And if I do this for the way code folder the only differing part (besides timestamps and [Nms]s) is this one (note that there's suddenly a git version - not sure if that can mean something or not):
Using git 2.25.1 from git@lszomoru correction for 1. - the parent folder is symlinked and yes the problem seems to be sourced there - when I choose open with/open folder in the real location, it acts the same as if opened with code folder. But how is it that both SCM know where the files are therefore know where the .git is but still don't show the gutters? Seems like some wrong path passing from Explorer/Tabs to SCM ? (I still consider this a bugged behavior)
lszomoru
commented
2 years ago @realjjaveweb, thank you very much for the clarifications. The git extension relies on file system events to perform various tasks like refreshing the list of changes, or refresh the diff decorators that are being displayed in the editor gutter. There was explicit work in the past, so that when you open a folder using the cli (ex: code foo) the symbolic links are not resolved. This means that the file system events that are being sent to extensions use URIs that contain the symbolic link instead of the real path of the file.
In the git extension, we use a git command to determine the location of the repository. This git command always resolves symbolic links and there is no way to control that behaviour. This results in a mismatch between the URIs that the git extension receives from VS Code, and the location of the repository as far as the git extension goes.
At the moment, when symbolic links are involved, the only workaround is to open such folders using the "File -> Open Folder" menu as in that case, the OS will resolve the symbolic links (at least based on my tests) and VS Code will use the real path, which will match the one known by the git extension.
realjjaveweb
commented
2 years ago @lszomoru
Ok thank you :slightly_smiling_face: , but it's the other way around - project folder symlink is resolved through code but not through open with/open folder.
In any case - is there a solution how to force symlink resolution for open with/open folder being implemented or does it rely on this being closed/resolved? : https://github.com/microsoft/vscode/issues/34627
Also I'm confused why the issue you've linked and there-mentioned issues are closed but the last comment there obviously not addressed nor resolved O.o do you please maybe have a little bit more insight? Thank you :slightly_smiling_face:
lszomoru
commented
2 years ago Ok thank you 🙂 , but it's the other way around - project folder symlink is resolved through code but not through open with/open folder.
My understanding is (which is supported by my tests) is that when you run code symlinks are being maintained, based on the changes that were implemented as part https://github.com/microsoft/vscode/issues/18837. When you use "File -> Open Folder" than the OS will resolve the symlink into the canonical URI, and pass the canonical URI to VS Code.
In any case - is there a solution how to force symlink resolution for open with/open folder being implemented or does it rely on this being closed/resolved? : https://github.com/microsoft/vscode/issues/34627
I do think that having a setting described in https://github.com/microsoft/vscode/issues/34627 would help in this particular case as one would be able to disable that functionality hence VS Code would always use the canonical URI independent on how a folder/workspace with a symlink is being opened. I would recommend that you subscribe to that issue.
Also I'm confused why the issue you've linked and there-mentioned issues are closed but the last comment there obviously not addressed nor resolved O.o do you please maybe have a little bit more insight? Thank you 🙂
There are multiple issues that have been filed over the years with various problems related to source control that are caused by symlinks. I will have a conversation with the team to seem if there is anything that we can do to improve that experience.
realjjaveweb
commented
2 years ago @lszomoru thank you for the links, effort with team and explanations :slightly_smiling_face:
BTW I did test it too and my test shows on Linux(Ubuntu) that if I open code folder I definitely see the resolved links in the header of the file opened from Explorer and the gutters are working and the other way around when I use open with/open folder - so could this be OS specific? (note that I am talking about the "folder"'s parent being a symlink, not symlinks within the project folder.
Noprop
commented
2 years ago @lszomoru hey, I've been working on these issues the last few weeks. I've actually fixed #5970 git symlink support but I'm hesitant to make a pull request. While a useful bandaid fix, it still doesn't fix the root cause.
You're right on the money where you can open your file/folder through "File -> Open Folder" and the OS will resolve it. The problems arise when you're using a remote version of VSCode and there is a symbolic link.
I've spent some time looking into resolving the symlinks before opening anything and while this is a super simple fix, it won't work because of Node package restrictions in the common directories.
Unless we can abstract the file opening to a less restrictive directory it seems impossible to solve the root problem. If you have any ideas lmk
lszomoru
commented
2 years ago @Noprop, thank you very much for the follow-up. We will continue to explore options to make this experience better.
Version: 1.42.0 (system setup) Commit: ae08d5460b5a45169385ff3fd44208f431992451 Date: 2020-02-06T10:51:34.058Z Electron: 6.1.6 Chrome: 76.0.3809.146 Node.js: 12.4.0 V8: 7.6.303.31-electron.0 OS: Windows_NT x64 10.0.18362
Steps to Reproduce:
Expected result: gutters should be visible when a git tracked files has changes
Actual result: gutters are only visible when the file is opened the way it is depicted in #41642
Does this issue occur when all extensions are disabled?: Yes (only gitlens was installed)
More info: The log below is from GitLens, but I feel that the issue is VSCode Git itself. Thus, opening it here. Both gutters and line blames in gitlens start working as soon as I open the file from the changes tab by right clicking on Open File.
GitLens log:
My git config: