[Tyrie Vella (tyrielv)]

Problem and Context

Enlistment.DotGitRoot and the path that GitProcess passes to --git-dir look like duplicate state.
In a linked worktree, they must point to different paths.

Enlistment.DotGitRoot points to the shared git directory.
GVFS uses that path when it reads or writes shared repository state directly.
Examples include objects, objects/info/alternates, and hooks.

GitProcess must pass the worktree .git file to --git-dir.
This is unintuitive, because that path is a file with a gitdir: pointer.
Git accepts the file path and resolves the pointer itself.
GitProcess must not pre-resolve the gitdir: target.

Given the .git file, Git resolves files in the per-worktree git directory by default.
Examples are HEAD, index, ORIG_HEAD, logs/HEAD, MERGE_HEAD, FETCH_HEAD, rebase-merge/, refs/bisect, and refs/worktree.
Only an explicit shared set goes through commondir to the shared git directory: config, objects, packed-refs, refs/heads, and hooks.
If GitProcess used Enlistment.DotGitRoot, linked worktree commands would bind to the main worktree.
For example, rev-parse HEAD and name-rev --name-only HEAD would report the main worktree.

Changes

• Document that Enlistment.DotGitRoot is shared repository metadata that subclasses supporting linked worktrees set during construction.
• Rename the private GitProcess field to gitDirPath.
• Document why GitProcess passes the worktree .git file to --git-dir.
• Make MockGitProcess record the --git-dir value that reaches InvokeGitImpl, and add constructors for a specific enlistment and for a bare working directory root.
• Add a test that a linked worktree passes its .git file, not DotGitRoot or the gitdir: target.
• Add a test that a regular enlistment passes a --git-dir that matches DotGitRoot.
• Add a test that no --git-dir is passed when the working directory root is null.

No production behavior changes.

[Marli Remash (mashmouse)]

Left some comments to bulk up my understanding.

[Nathan Baird (ShiningMassXAcc)]

Review pass over this PR. 5 comment(s).

These findings concern code the diff does not touch directly, so GitHub cannot anchor them inline:

GVFS/GVFS.FunctionalTests/Tests/EnlistmentPerFixture/WorktreeTests.cs (around line 430) - MEDIUM

The behavior motivating this PR — that a command run in a linked worktree reports that worktree's HEAD and branch rather than the primary enlistment's — is not asserted anywhere. The existing tests cover mount liveness, git status --porcelain, projected file visibility and the per-worktree placeholder database, all of which would still pass if git-dir resolution regressed.

A single assertion that rev-parse HEAD (or rev-parse --abbrev-ref HEAD) in the worktree differs from the primary enlistment's would close that gap directly.

[Tyrie Vella (tyrielv)]

Note

🤖 Machine-drafted reply, reviewed and approved by Tyrie Vella (@tyrielv) before posting.

The functional harness invokes git directly rather than through GitProcess, so a rev-parse assertion there would not catch a regression in the --git-dir that GitProcess passes. The new unit tests pin that wiring instead.

[Nathan Baird (ShiningMassXAcc)]

Re-review of the second commit. All four of my earlier threads are addressed, and the pinning change itself looks right — thank you. One correction to the new comment plus three nits below; none of them block.

CI is green across every leg.