[Bug]: Diff view drops intermediate directories for a nested git repo under a non-git project root #12902

Activity

1. Catalan-1ap

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 21, 2026
2. juliusmarminge commented on Sep 21, 2026

   

   juliusmarminge

   on Sep 21, 2026

   Member

   More actions

   Triage

   Confirmed as a path-mapping bug, not a bad local setup. Opening a file from the Diff panel for a git repo nested two or more levels under a non-git project root joins the wrong relative path to the project root.

   Reported failure:

   Failed to read workspace file 'kubernetes-pak-cl-dev/lms-platform/web/backoffice/values.yaml.gotmpl' in 'E:\Work\FinBeat'
   

   Expected location:

   E:\Work\FinBeat\Kubernetes\kubernetes-pak-cl-dev\lms-platform\web\backoffice\values.yaml.gotmpl
   

   The Kubernetes\ segment between the project root and the clone is dropped. A clone sitting directly under the project root works, because <repo dir name>/<git-relative path> happens to be the full workspace-relative path.

   Diagnosis

   The error string is ProjectReadFileError in packages/contracts/src/project.ts. Diff-panel open goes through apps/web/src/components/DiffPanel.tsx → openDiffFilePrimaryAction / resolveDiffPathForWorkspace in apps/web/src/diffFileActions.ts → rightPanelStore.openFile → project.readFile with cwd = the project workspace root.

   resolveDiffPathForWorkspace only handles workspace inside repo: it strips the workspace prefix from a repo-relative path. When the repo is inside the workspace (this report), repositoryRelativeWorkspaceSegments returns null and the path is used as-is. Git status, review diffs, and checkpoint numstat in apps/server/src/vcs/GitVcsDriverCore.ts / apps/server/src/orchestration/Layers/CheckpointReactor.ts are repository-relative. RepositoryIdentityResolver also runs git rev-parse --show-toplevel from the project cwd, so a non-git root has no repositoryIdentity.rootPath for the UI to recover the full offset.

   That matches the reporter’s construction: <repo dir name>/<path relative to the repo root> joined onto the project root.

   This is the inverse of #2441 / #9842 (workspace subdirectory of a git repo). Those fixes do not cover a non-git parent with clones underneath.

   #9816 is the open multi-repo Diff-panel feature for this layout (t3.json repositories). Review there already flagged nested-repository path resolution. It is not merged and should not be treated as a fix for 0.0.42.

   Next step

   Small, targeted fix plus a regression test:

   1. When repositoryRoot is under workspaceRoot, build the workspace path as relative(workspaceRoot, repositoryRoot) + the git-relative file path, keeping every intermediate directory (not basename(repoRoot)).
   2. Cover the Windows fixture E:\Work\FinBeat\Kubernetes\kubernetes-pak-cl-dev\lms-platform\web\backoffice\values.yaml.gotmpl.
   3. Keep #9816 in the loop so the multi-repo Diff work uses the same offset.

   Until that lands, the existing workaround stands: open the nested clone as its own T3 Code project, or inspect the change with git diff in the terminal.

   Not a duplicate. Repro is sufficient to implement; no extra reporter info needed.
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 21, 2026
4. leorivastech commented on Sep 25, 2026

   

   leorivastech

   on Sep 25, 2026

   Contributor

   More actions

   Hi, I'd like to take this one.

   I'd follow the next step above: when the repo is under the workspace, build the path from relative(workspaceRoot, repositoryRoot) plus the git-relative path instead of the repo basename, with the Windows fixture as a regression test. I'll keep it small so #9816 can reuse the same offset.

   Happy to hold off if you'd rather handle it yourselves.