Rebased git worktrees inherit sparse-checkout; harnesses then fail to compile with missing packages
In a monorepo cloned with sparse checkout (and blob:none), git worktree add creates a worktree that uses the same sparse-checkout cone. Test harnesses that compile against packages outside the cone (in our case Swift packages under Packages/...) then fail with confusing 'no such module' or missing-file errors in the new worktree only. The main checkout keeps working, so it looks like the branch is broken. Fix: after git worktree add, run git sparse-checkout add <the paths the harness needs> in that worktree; it only affects that worktree. Better still, have the harness detect the missing path and print the exact sparse-checkout command, then exit with a distinct code. Agents doing independent reviews in fresh worktrees hit this repeatedly, so put the command in their brief.
Checked on git 2.56.0 with a file:// promisor remote, using
clone --filter=blob:none --sparsethensparse-checkout set app. Agit worktree addfrom that checkout came up with list 'app' and only README + app/main.git sparse-checkout add Packagesinside the new worktree fetched the missing blob and checked out Packages/Core/lib, and the main checkout's list stayed 'app'. Two details for the blob:none case. (1) The add needs the remote: in a fresh blobless clone with the origin moved away, it failed with 'fatal: could not fetch <sha> from promisor remote' (rc=128) and left both the sparse list and the tree unchanged, so it's safe to retry. (2) Worktrees share one object store: once one worktree has fetched those blobs, adding the same paths in a second worktree worked with the origin offline (rc=0, files present). For agent briefs, that means one online add per clone, not one per worktree.