Supercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more
When using VSCode as the editor for interactive rebase (git rebase -i), commands like "open changes" when activated from a commit details side panel spawned by clicking on a commit hash inside an interactive rebase preview (/path/to/repo/.git/worktrees/worktree-name/rebase-merge/git-rebase-todo), often fail, producing errors like:
Open File - Unable to open "relative/path"Unable to open working file. File could not be found in the working tree
When they do work, the path displayed for the file at relative/path matches the main worktree (/path/to/repo/...) rather than the current worktree (/path/to/worktree/...), unlike when "Open changes with previous revision" is called from the context of an editor with the working directory inside the worktree (/path/to/worktree/relative/)
Looks like it might be caused by incorrectly identified worktree paths when opening git-rebase-todo, see the console output below.
Expected behavior
Instead of using the /path/to/repo/.git/worktrees/worktree-name/rebase-merge/ path inferred from the location of the git-rebase-todo file and trying to get the worktree location using rev-parse --show-toplevel, it should either explicitly use the path from .git/worktrees/worktree-name/gitdir or use a different mechanism that doesn't rely on the working directory being outside of .git.
[2024-05-20 12:54:12.715] [ 10ms] [/path/to/repo/.git/worktrees/worktree-name/rebase-merge] git rev-parse --show-toplevel • FAILED
Error: Command failed: /usr/local/bin/git -c core.quotepath=false -c color.ui=false rev-parse --show-toplevel
fatal: this operation must be run in a work tree
Description
When using VSCode as the editor for interactive rebase (git rebase -i), commands like "open changes" when activated from a commit details side panel spawned by clicking on a commit hash inside an interactive rebase preview (
/path/to/repo/.git/worktrees/worktree-name/rebase-merge/git-rebase-todo), often fail, producing errors like:Open File - Unable to open "relative/path"Unable to open working file. File could not be found in the working treeWhen they do work, the path displayed for the file at
relative/pathmatches the main worktree (/path/to/repo/...) rather than the current worktree (/path/to/worktree/...), unlike when "Open changes with previous revision" is called from the context of an editor with the working directory inside the worktree (/path/to/worktree/relative/)Looks like it might be caused by incorrectly identified worktree paths when opening
git-rebase-todo, see the console output below.Expected behavior
Instead of using the
/path/to/repo/.git/worktrees/worktree-name/rebase-merge/path inferred from the location of thegit-rebase-todofile and trying to get the worktree location usingrev-parse --show-toplevel, it should either explicitly use the path from.git/worktrees/worktree-name/gitdiror use a different mechanism that doesn't rely on the working directory being outside of.git.GitLens Version
15.0.3
VS Code Version
Version: 1.89.1 Commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685 Date: 2024-05-07T05:14:24.611Z (1 wk ago) Electron: 28.2.8 ElectronBuildId: 27744544 Chromium: 120.0.6099.291 Node.js: 18.18.2 V8: 12.0.267.19-electron.0 OS: Darwin x64 23.4.0
Git Version
git version 2.44.0
Logs, Screenshots, Screen Captures, etc