[Tyrie Vella (tyrielv)]

Problem and Context

Each linked git worktree of a GVFS enlistment runs its own GVFS.Mount.exe. At mount, the worktree wrote gvfs.mount-id, gvfs.enlistment-id, and the required setting status.deserializePath with git config --local.

Git resolves --local config for a linked worktree to the shared .git/config, not to a per-worktree file. So each worktree mount overwrote values that belong to the primary enlistment:

• Ids: the primary lost its own gvfs.mount-id and gvfs.enlistment-id, which broke telemetry correlation.
• Status cache: each enlistment serializes git status to a cache under its own .gvfs directory. The shared status.deserializePath pointed every enlistment at the cache of whichever enlistment mounted last. microsoft/git rejects a cache that does not match the index of the reader, so every other enlistment, the primary too, silently lost the status cache.
• Concurrency: parallel worktree mounts wrote the shared config at the same time. A concurrent reader can fail with unable to access '.git/config': Permission denied.

Changes

Required config

• RequiredGitConfig.TrySetRequiredSettings is now the single helper for required settings. Mount, gvfs clone, and gvfs repair use it, which replaces two copies of the same loop.
• For a linked worktree, the helper enables extensions.worktreeConfig in the shared config. It writes status.deserializePath to .git/worktrees/<name>/config.worktree with git config --file. Git then uses the worktree value for that worktree and the shared value for the primary.
• An unattended worktree writes an empty status.deserializePath to its config.worktree. The empty value replaces a path that an earlier attended mount wrote. It does not disable a readable shared path, because microsoft/git uses the last readable path. Git rejects the cache of the primary in a worktree, because that cache does not match the worktree index.
• A mount without a status cache (unattended, or a platform without the cache) deletes the GitStatusCache.dat of its enlistment before it reports ready. Nothing updates that file while the mount runs, but git reads it when status.deserializePath names it. A worktree mount writes the path of the primary to the shared config again, so an unattended primary otherwise reads an old cache. The mount retries the delete five times, and then fails.
• The shared config keeps the status cache path of the primary. A worktree mount restores that value when an older version overwrote it.
• A config.worktree value overrides the shared value when the extension is on. So the helper removes every other required setting from the config.worktree of the enlistment, for the primary too.
• The primary also enables the extension when a linked worktree has a config.worktree. So gvfs repair on the primary keeps the extension.
• The helper reads every config entry with git config --list -z. A required setting is correct only when it has exactly one entry with the required value. Git uses the last entry of a key. So the helper rewrites a key that has several entries, or an entry without a value, with --replace-all. This also applies to extensions.worktreeConfig.
• The removal from config.worktree also finds a required key that has no value.
• A failed shared write is retried up to five times. It counts as done when a new read of the shared config shows exactly that value, because concurrent worktree mounts write the same values. This retry also applies to the primary, clone, and repair.
• The helper reads the local config and config.worktree with the config read retry from Retry transient Git config reads #2130. The mount passes its tracer to the helper, so the retries are traced.
• Setting names with a quoted subsection, such as credential."https://dev.azure.com".useHttpPath, now match the output of git config --list. Before this change, every mount of every enlistment rewrote that setting in the shared config.
• Clone and repair now show the error from the helper.
• Optional settings use a smaller helper, TrySetMissingConfig, that sets only missing keys. Its behavior does not change.

Ids

• GVFS.Mount creates the mount id before it creates its tracer. Every telemetry event of a mount now carries the id of that mount. Before this change, the tracer read the id of the previous mount from git config. This applies to the primary too.
• The mount reads the primary enlistment id one time, before it creates its tracer. The tracer and the worktree metadata use the same derived id.
• For the primary, GetEnlistmentId reads the repo metadata first, and then the shared config.
• A worktree writes gvfs.mount-id to its config.worktree.
• The enlistment id of a worktree is derived from the primary enlistment id and the worktree name: the first 16 bytes of SHA-256, as 32 lowercase hex characters. The worktree mount stores it in the repo metadata of the worktree, so heartbeat and lock telemetry report the same id. The id does not change when the worktree moves.
• The EnlistmentInfo event of a worktree mount adds PrimaryEnlistmentId, so telemetry can relate a worktree to its primary.
• A worktree mount restores the shared gvfs.enlistment-id of the primary when an older version overwrote it.
• Warnings about a missing primary enlistment id, a failed mount id write, and a failed restore of the shared id go to telemetry.

Why the ids do not use config.worktree

git worktree add, when it runs inside a linked worktree, copies the config.worktree of that worktree into the new worktree. If a worktree stored its enlistment id there, the new worktree gets the same id. The mount rewrites gvfs.mount-id and status.deserializePath on every mount, so a copy of those values does no harm. The enlistment id is derived instead of stored.

Tests

• Add unit tests in WorktreeEnlistmentTests that run real git against a worktree layout. The tests check:
  • the extension and per-worktree values, and that the shared value of the primary is kept or restored;
  • the empty value for an unattended worktree, the removal of required overrides from config.worktree, and duplicate extension values;
  • the primary behavior with and without a linked config.worktree, and a corrupt config.worktree;
  • that a second application of the required settings writes nothing, for the primary and for a worktree;
  • that a read of the primary enlistment id succeeds when the metadata lock is released during the retry;
  • that worktree metadata keeps a given or stored enlistment id, and creates a new id when neither is present or the stored id is blank.
• Add unit tests in WorktreeEnlistmentTests that pin the derived enlistment id to a known value. These tests also cover worktree-name case and the fallback to the stored id when the primary metadata is missing or locked.
• Add unit tests in RequiredGitConfigTests that use MockGitProcess. They cover a failed shared write that another process completed, a retry that succeeds, a write that keeps failing, an unreadable local config, a quoted-subsection setting that is already present, a key with several values, a key without a value, and a failed write whose new read shows a second value.
• Add the functional test WorktreeTests.WorktreeMountUsesPerWorktreeConfigAndKeepsPrimaryValues. It mounts and remounts a real worktree and checks that the primary keeps its ids and status cache path. It also checks that the worktree has its own status cache path, a stable enlistment id, and a new mount id on each mount. The test reads the EnlistmentInfo event from the mount log of the worktree and checks its mountId, EnlistmentId, and PrimaryEnlistmentId against the stored values.
• Add the functional test WorktreeTests.WorktreeMountRepairsConfigLeftByPreviousVersion. It recreates the state that an older version leaves, mounts only the worktree, and checks that the shared values of the primary and the worktree values are repaired. The test restores the shared values when it ends.
• Add the functional test WorktreeTests.UnattendedMountDeletesTheStatusCacheThatItDoesNotUpdate. The test builds an attended status cache, remounts the primary unattended, and checks that the cache file is gone. It then writes the shared path again, as a worktree mount does, and checks that git status shows a new file.

Known gaps and deliberate decisions

• Transient errors in other git readers — A git process that reads .git/config while GVFS replaces it can fail with Permission denied. GVFS readers retry this failure since Retry transient Git config reads #2130. This change limits shared writes to the repair of wrong values, but git processes outside GVFS do not retry. No follow-up planned.
• Rollback — An older GVFS version ignores config.worktree and leaves extensions.worktreeConfig enabled. Inside the worktree, git config gvfs.mount-id then returns the last mount id that this version wrote. The older version reads the id with --local, so GVFS itself is not affected. No follow-up planned.
• Shared core.worktree — When the extension is enabled, git applies a shared core.worktree to linked worktrees too. GVFS clones do not set core.worktree, so this change does not migrate it. No follow-up planned.
• Worktree metadata is written before the mount lock — InitializeWorktreeMetadata saves repo metadata before it takes the per-worktree mount lock. A second concurrent mount of the same worktree can retry the metadata replace for a long time instead of reporting that a mount is already running. This behavior predates this change. No follow-up planned.
• Shared mount id after an older version — After an older worktree mount overwrote the shared gvfs.mount-id, the value stays wrong until the primary mounts again. Only telemetry tooling reads that value.
• Config includes — git config --list --local and --list --file do not expand include.path or includeIf. A required setting that comes from an included file is not checked or removed. This gap already exists for the shared .git/config. GVFS does not write includes. No follow-up planned.
• Unattended worktree mount — An unattended worktree mount does not restore the shared status.deserializePath of the primary. The next mount of the primary, or the next attended worktree mount, restores it. No follow-up planned.
• Readers while the mount id changes — The mount rewrites gvfs.mount-id in config.worktree on each mount. A git process in that worktree that reads its config at the same moment can fail. The window is one small file write per mount. GVFS readers retry this failure. No follow-up planned.

[Keith Klein (KeithIsSleeping)]

[KeithBot]: ⚠️ 1 issue · iteration 7 (5bdfb37)

1. 🟡 Medium Unattended mounts can make git status read a stale status cache and miss edits

Validation

• ❌ Status-cache sequences, real git
• ✅ GVFS.UnitTests full suite, source + base
• ✅ Changed fixtures 319 vs 292 at base
• ✅ CI functional XML, new worktree tests
• ✅ Real-git config probes (races, keys)

_{🤖 KeithBot · claude-opus-5.5, gpt-6.1-sol, gemini-4-argon · reply on a thread to dispute}

[Keith Klein (KeithIsSleeping)]

[KeithBot]: ✅ Resolved · iteration 8 (d930947)

• Unattended mounts can make git status read a stale status cache and miss edits: fixed
• New changes since iteration 7: no new issues

Validation

• ✅ Status-cache S1/S2 replay, real git
• ✅ Real delete method, real files (r1-r3)
• ✅ GVFS.UnitTests full suite (r1, r3)
• ✅ GVFS.CommandLine.Tests + compiles (r1-r3)
• ✅ CI run on head, slice-3 per-case XML

Approving.

_{🤖 KeithBot · claude-opus-5.5, gpt-6.1-sol, gemini-4-argon · reply on a thread to dispute}