fix: resolve git origin in linked worktrees (Tia storage key + baseline fetch)

[dammyammy]

Problem

In a linked git worktree (git worktree add), .git is a file containing a gitdir: pointer, not a directory. Two TIA code paths read <projectRoot>/.git/config directly with file_get_contents, so both silently fail in every linked worktree:

1. Storage::rawOriginUrl() — the project key falls back to a hash of the absolute path instead of the normalized origin URL. The TIA docs promise:

   Sharing state per remote URL means multiple worktrees of the same repository share one cache, while unrelated projects on the same machine stay isolated.

   In a linked worktree that promise doesn't hold today — every worktree gets an unrelated path-derived key.

2. BaselineSync::detectGitHubRepo() — returns null, so --tia --baselined silently skips the CI baseline fetch and falls back to a full local re-record. This bites hardest exactly where the baseline fetch matters most: fresh, short-lived worktree checkouts (CI shards, coding-agent worktrees) that have no local graph to reuse.

Reproduction (measured on v5.0.2)

pest --baseline prints the resolved storage directory:

# main checkout
$ vendor/bin/pest --baseline
/Users/x/.pest/tia/repo-840a07cab1e2d72d        # hash derived from origin URL

# linked worktree of the same repository — before this fix
$ cd ../repo-wt && vendor/bin/pest --baseline
/Users/x/.pest/tia/wt-feee7be378801f90          # hash of realpath — origin ignored

# linked worktree — after this fix
$ vendor/bin/pest --baseline
/Users/x/.pest/tia/wt-840a07cab1e2d72d          # origin-derived hash again

To reproduce from scratch: git worktree add ../repo-wt on any repo with an origin remote, composer install in the worktree, run vendor/bin/pest --baseline in both checkouts and compare the hashes.

Fix

• Keep the existing fast .git/config file read for regular checkouts — behaviour there is unchanged, no process is spawned.
• When .git exists but is not a directory (linked worktree), fall back to git config --get remote.origin.url executed in the project root. Git resolves the gitdir: pointer natively, so worktrees behave like regular clones.
• The subprocess has a 5s timeout, and every failure mode (git binary missing, no origin remote, non-zero exit) degrades to the existing null behaviour — a worktree without a resolvable origin keeps today's path-hash fallback.
• BaselineSync::detectGitHubRepo() now derives the URL through the same resolution, so both call sites agree on what the origin is.

Related work — checked, not duplicates

• [Bug]: In a git worktree every TIA fingerprint input is null, so composer.lock / phpunit.xml changes never invalidate the graph #1810 / Fix TIA fingerprinting inside linked git worktrees #1813 fix Fingerprint::isTrackedByGit(), which breaks in linked worktrees for the same root cause (Symfony Finder doesn't resolve the gitdir: pointer). Different defect, different file — this PR is complementary and touches neither Fingerprint.php nor the paths changed there.
• fix: support Tia when the Pest project is a subdirectory of the git repository #1805 / feat(tia): support projects in git repository subdirectories (monorepos) #1809 address TIA for projects in repository subdirectories; Fix project root resolution when vendor is a symlinked directory (git worktree support) #1752 addresses project-root resolution with a symlinked vendor. Neither touches origin resolution.

Tests

tests/Unit/Plugins/Tia/Storage.php and tests/Unit/Plugins/Tia/BaselineSync.php create real temp repositories (plus a linked worktree via git worktree add) and cover:

• the storage key is derived from the origin remote in a regular clone, and resolves to the same origin hash inside a linked worktree;
• the path-derived fallback still applies when there is no origin remote;
• detectGitHubRepo() resolves owner/repo from ssh and https origins, resolves it inside a linked worktree, and returns null for non-GitHub or missing origins.

Verified both ways: all 8 pass on this branch, and with src/Plugins/Tia/{Storage,BaselineSync}.php reverted to 5.x exactly the two worktree tests fail (path hash instead of origin hash; null instead of foo/bar) while the six regular-checkout tests keep passing — i.e. behaviour outside worktrees is unchanged.

Notes for review

• Storage::projectKey() still prefixes slug(basename($projectRoot)), so two worktrees end up with sibling storage dirs (repo-<hash>, wt-<hash>) that share the origin-derived hash, rather than literally one shared directory. If literal sharing (the docs' wording) is preferred, the slug would also need to derive from the origin identity — happy to extend the PR that way. Keeping per-worktree keys does avoid concurrent runs in different worktrees racing on the same graph.json.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[joshdaugherty]

Before this merges, it seems worth settling whether the folder name belongs in <project-key>.

1. If two checkouts share a cache only when the origin identity and the folder name both match, then the folder name belongs in <project-key>.
2. If any two checkouts of one repo share a cache regardless of their folder names, then the folder name does not belong in <project-key>.

The docs describe the second:

Pest stores its state at ~/.pest/tia/<project-key>/, where the project key is derived from your normalized git remote URL [...]

Sharing state per remote URL means multiple worktrees of the same repository share one cache, while unrelated projects on the same machine stay isolated.

The code does the first. projectKey() puts slug(basename($projectRoot)) in front of the hash of originIdentity(), which is the host plus org/repo, so the path is really ~/.pest/tia/<folder-slug>-<origin-hash>/ and both halves have to match for two checkouts to share.

That is already true today, before this PR. Measured on v5.0.3 and on your branch (00c5ea87), with real git init, git clone and git worktree add.

Two clones with the same folder name share a cache:

checkout	key today	key with this PR
clone a/proj	proj-8f123dcf425b3cf3	proj-8f123dcf425b3cf3
clone b/proj	proj-8f123dcf425b3cf3	proj-8f123dcf425b3cf3

Two clones with different folder names do not share a cache:

checkout	key today	key with this PR
clone a/proj	proj-8f123dcf425b3cf3	proj-8f123dcf425b3cf3
clone a/different-name	different-name-8f123dcf425b3cf3	different-name-8f123dcf425b3cf3

A main checkout and its worktree do not share a cache either:

checkout	key today	key with this PR
main checkout alt/repo	repo-cccd236c3d935c7e	repo-cccd236c3d935c7e
worktree alt/wt	wt-27fd7729adb03709	wt-cccd236c3d935c7e

In the first two examples, the hash is identical, so sharing by origin identity already works for clones and only the prefix separates them. This PR changes nothing there.

In the third example, the hashes differ as well, and that is the bug this PR fixes.

The bug: in a linked worktree .git is a file holding a gitdir: pointer, not a directory. rawOriginUrl() checks is_file(<root>/.git/config), which is false there, so it returns null and projectKey() hashes the absolute path instead of the origin identity. The worktree gets a path-derived hash while its main checkout gets an origin-derived one, which is why wt-27fd7729adb03709 and repo-cccd236c3d935c7e have nothing in common.

The fix: when the config can't be read directly, ask git for it with git config --get remote.origin.url in the project root. Git resolves the pointer itself, so the worktree gets the same origin identity as its main checkout, and alt/wt becomes wt-cccd236c3d935c7e.

The hashes now match, so the worktree follows the same rule as clones. But repo- and wt- still keep the two apart, so they still do not share a cache. (Hash values depend on the paths and origin used, so only the matching pattern reproduces elsewhere.)

What that leaves open is the prefix, and it isn't something this PR introduces: two clones in differently named folders already don't share.

Is the folder name meant to be part of the key, or is it a readability aid that ended up in it? If it's intended, the docs are what needs updating. If not, dropping it would make the documented behavior true for clones and worktrees alike.