[BUG] Relative paths inexplicably cause file history to fail in symlinked folder circumstances.

[Eoin O'Neill]

Describe the Bug

While git log features work and basic history searching seems functional, it seems that my current system creates a strange behavior where the path is being referenced to as the wrong relative path. This is probably system dependent as I have a docker/podman container (technically distrobox container) that I run visual studio code within that has a unique home folder. I symlink to my "real" code folder from my host home. Since paths are not canonicalized by this plugin, it cannot determine that the two paths point to same git directory (git itself does not seem to like this either.)

I have an overly complex setup compared to most users so the problem is likely not urgent, but it's worth knowing that symlinks might create strange behavior for users who have complex needs due to their system configuration (in my case, I'm using an immutable operating system where pet containers are a necessity.) VSCode seems to automatically canonicalize the paths to when dealing with git, but the behavior is not matched by the plugin which attempts to keep relative pathing but to the wrong folder structure. If I bypass the symlink by going directly to the target directory, this problem is resolved but it's a minor inconvenience.

Steps To Reproduce

On linux systems, you could do something akin to the following:

1. Install distrobox, create a custom home for an ubuntu image. See distrobox for more details. Custom home should be a location like ~/.container_hom/vscode_home.
2. Install vs code as one would for ubuntu using the deb file and running apt install ./code_****.deb. Install this plugin.
3. Symlink your code folder (lets say host ~/Code) to your guest system's home (canonical path ~/container_home/vscode_home/Code). Open your project through that symlinked path.
4. Try to view file history after viewing general git history. You'll see an output akin to the below:

git rev-list --full-history --count master --  (completed in 0.277s)
git log --full-history --pretty=oneline --date-order --decorate=full --skip=0 --max-count=100 master --  (completed in 0.31s)
git shortlog -e -s -n HEAD  (completed in 0.366s)
git rev-list --full-history --count master -- ../../../../../Code/godot/repo/core/object/worker_thread_pool.cpp  (completed in 0.009s)
fatal: ../../../../../Code/godot/repo/core/object/worker_thread_pool.cpp: '../../../../../Code/godot/repo/core/object/worker_thread_pool.cpp' is outside repository at '/home/eoin/Code/godot/repo'

git log --full-history --pretty=oneline --date-order --decorate=full --skip=0 --max-count=100 master --follow -- ../../../../../Code/godot/repo/core/object/worker_thread_pool.cpp  (completed in 0.07s)
fatal: ../../../../../Code/godot/repo/core/object/worker_thread_pool.cpp: '../../../../../Code/godot/repo/core/object/worker_thread_pool.cpp' is outside repository at '/home/eoin/Code/godot/repo'

5. Conversely, opening the canonical path of the folder directly will work as expected (in my case, opening ~/Code/godot/repo works but opening ~/.container_home/vscode_home/Code/godot/repo does not.)

Expected Behavior

Ideally both paths would be canonicalized and then forced to be relative to the git repository. In the above example, the path should be made relative to /home/eoin/Code/godot/repo. If this cannot be done, then the file is not part of the project and the ability to view the file log should error stating such.

Environment

• OS: Fedora Silverblue 39
• VSCode version:

Version: 1.84.2
Commit: 1a5daa3a0231a0fbba4f14db7ec463cf99d7768e
Date: 2023-11-09T10:50:47.800Z
Electron: 25.9.2
ElectronBuildId: 24603566
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.5.12-300.fc39.x86_64

• Git History version: v0.6.20