A fork's files page reads its drift from the parent under 3 ms when neither tip has moved #6317

Fork drift is cached by tip pair, and a warm read spawns no git. Nothing new was committed this run, because the branch already held the work and matches origin. I did not push.

• Cache: forkDrift in src/actions/forks.ts keys its answer by (parent tip, fork tip). The tips are read straight from the ref files via readBranchTip in src/git/tips.ts. Git runs only when a tip has moved or a ref is packed. The cache is an in-memory Map that is cleared when it reaches STANDING_MAX entries. It is separate from the followingOf cache in #6127.
• Test: test/fork-drift-cache.test.ts asserts three things. The first read returns ahead 1, behind 0. A second read leaves Bun.spawn uncalled. After a commit to the parent, the next read returns behind 1.
• Verified this run: the drift test and the fork tests (23 tests) pass, and tsc --noEmit is clean. The run logged one ENOENT ... posix_spawn 'git' error from the following code during setup; it did not fail any test.
• Left out: the test has no 3 ms wall-clock assertion. Timing bounds are flaky on a loaded machine, so the no-spawn check stands in for the "under 3 ms" criterion. I did not measure the files page itself against the 3 ms figure.

Closes #6146

Fork drift is cached by tip pair, and a warm read spawns no git. Nothing new was committed this run, because the branch already held the work and matches origin. I did not push.

• Cache: forkDrift in src/actions/forks.ts keys its answer by (parent tip, fork tip). The tips are read straight from the ref files via readBranchTip in src/git/tips.ts. Git runs only when a tip has moved or a ref is packed. The cache is an in-memory Map that is cleared when it reaches STANDING_MAX entries. It is separate from the followingOf cache in #6127.
• Test: test/fork-drift-cache.test.ts asserts three things. The first read returns ahead 1, behind 0. A second read leaves Bun.spawn uncalled. After a commit to the parent, the next read returns behind 1.
• Verified this run: the drift test and the fork tests (23 tests) pass, and tsc --noEmit is clean. The run logged one ENOENT ... posix_spawn 'git' error from the following code during setup; it did not fail any test.
• Left out: the test has no 3 ms wall-clock assertion. Timing bounds are flaky on a loaded machine, so the no-spawn check stands in for the "under 3 ms" criterion. I did not measure the files page itself against the 3 ms figure.

forkDrift now caches its answer by (parent tip, fork tip), and a warm read spawns no git. This update removes the second ref reader.

• Second ref reader: forkDrift now reads the two tips through the existing readTips. readBranchTip is deleted, so src/git/tips.ts is back to its original contents. If a ref file isn't a plain object id, for example a symbolic or missing ref, forkDrift falls back to git as before. The drift test, the fork tests and tsc pass.
• 3 ms: I did not measure it, and the test doesn't either. It asserts that Bun.spawn is never called on the warm read, and that a commit to the parent changes behind on the next read. A wall-clock bound would be flaky on a loaded machine. The "under 3 ms" in the title is not backed by any measurement of the files page.
• FLOW ONLY: this is a performance feature for fork drift and isn't among #6263, #5930, #6217 or #5994. I haven't held or closed the pull. Whether to hold it until the flow alarms clear is for a person to decide, and I'll do whichever they say. The change is small and self-contained.

A warm fork-drift read spawns no git, and I'm leaving this pull for a person to hold or land. There is nothing to change on the branch, so I did not push again.

What changed. forkDrift in src/actions/forks.ts now keeps its answer by (parent tip, fork tip). It reads both tips through the existing readTips, and falls back to git for a symbolic or missing ref. The cache is in-memory and bounded, and it is separate from the followingOf cache in #6127. test/fork-drift-cache.test.ts checks that a warm read leaves Bun.spawn uncalled, and that a commit to the parent changes behind on the next read.

What the pull does not claim. The "under 3 ms" in the issue title is not measured. The test proves only that no git process starts on a warm read. I read the juniper review as asking for the title to say that, but I can't retitle the pull from here. A person should retitle it "a warm fork-drift read spawns no git" if it lands.

Direction. Juniper's remaining objection is that this is a performance feature while #5930's flow alarms are not yet clear. That is a decision for a person, not me, and I won't argue against it. If the pull is held, no work is lost. The tests and tsc passed on the last push.

Try it. Run bun test test/fork-drift-cache.test.ts, or open a fork's files page twice. The second load runs no rev-list.

A fork's drift from its parent is now cached, so a warm read spawns no git. The pull needs a person to decide whether it lands now. Its title still says "under 3 ms", which nothing measures, so it should be retitled "a warm fork-drift read spawns no git". I could not retitle it, and the branch has no new changes to push.

forkDrift in src/actions/forks.ts keeps its answer by (parent tip, fork tip) in a bounded in-memory map. It reads both tips through the existing readTips and asks git only when a ref isn't a plain object id (a symbolic or missing ref). The cache is separate from the followingOf cache in #6127.

test/fork-drift-cache.test.ts checks two things:

• A warm read leaves Bun.spawn uncalled.
• A commit to the parent changes behind on the next read.

I ran the fork tests and tsc --noEmit on the last push; both passed.

I left out any wall-clock assertion, because it would be flaky under load. I also didn't measure the files page against 3 ms.

The review's remaining objection is direction: #5930's flow alarms must stay clear for 24 hours, and only #6263, #5930, #6217 and #5994 may be built until then. This pull is none of those, so a person should decide whether to hold it or land it. To try it, run bun test test/fork-drift-cache.test.ts.

Handed to a person by the crew: two follow-up runs on the review's changes ended without a push, so no more start here until you say what to try. (The forge posts this under the reviewer's name; the reviewer did not write it.)

Waits for flow only to be turned off. (The forge posts this under the reviewer's name; the reviewer did not write it.)