Before the First Snapshot

The first bug after the release was a worktree that arrived twice. Two snapshots, two seconds apart, both additions, both sitting at the top of a history that was supposed to begin with one hidden copy of the checkout. The recorder had found the worktree while Git was still filling it.

Metadata Is Not a Worktree

git worktree add writes .git/worktrees/<name> before the checkout is complete. Tachograph watches that metadata every two seconds, debounces a change by 600 ms, and starts a scan. On a small repository the checkout wins the race. On a large one it does not: the first snapshot stages the files that exist, the second stages the rest, and the timeline shows a piece of setup that was never work.

The precise fix is to look at the worktree’s own index.lock. While it exists, another Git process owns the checkout; a snapshot would only capture a half-written tree. The recorder returns ErrWorktreeBusy, the supervisor retries a second later, and no commit is created. But a lock covers Git, not the setup commands and generated files that can follow it. The recorder needed a rule for the whole first minute, not only for one lock file.

A Window, Not a Guess

The first snapshot is not a moment. It is the end of an initialization window, and the window has an explicit state. A new linked worktree stores initAt and initDone in its per-worktree config, and the last initialization commit is recorded in refs/tachograph/init/<worktree>.

While the window is open, every addition-only snapshot advances that ref and remains hidden. After each one the supervisor schedules a quiet check five seconds later. If the check finds no change, the worktree has settled and the window closes. A snapshot that modifies, deletes or renames a tracked file closes the window before it is committed, because that is work and belongs in the timeline. A ten-minute cap closes the window even when generated files never stop arriving. The main worktree is exempt: it is the source tree, and its history stays complete.

The Old Stores

Existing stores have no init keys and no ref. Rewriting them would change hashes, labels and deep links. Instead the timeline reads the leading run of addition-only snapshots, stops at the first real edit or at pauses longer than ten seconds, and uses the last addition as the hidden baseline. The whole prefix is capped at two minutes and 32 commits, so an old store cannot turn a normal new file into setup by accident. After the prefix is two minutes old, the next scan writes the ref and marks the store as managed. The fallback stays for stores that never get a scan, but the common case becomes an O(1) lookup.

The Whole Worktree

The same boundary makes a different view possible. Select all in the timeline combines every visible snapshot from the hidden baseline to HEAD. It is one range, not a list of patches: GET /api/v1/worktree-diff resolves the baseline and the newest commit per request. When SSE reports a new snapshot, the drawer re-fetches the range and the diff grows with the worktree. The view is read-only; reverting the hidden baseline would delete the files the worktree inherited. File selection still narrows the combined diff to one path.

The project list now carries the same numbers before the snapshot count, so a linked worktree reads as +128 -34 · 12 snaps instead of making the diffstats a detail of the activity table.

What Available Means

Tachograph is marked Available with the v0.7.1 binaries for Linux, macOS and Windows. Available is not a synonym for finished. It means the recorder has a working release, an install path, and enough history behind it to be used without a supervisor. Remote backup, a first-run experience, installers and smart open outside Linux are still open. The series ends here because the product has reached a stable state, not because the list is empty.

The Numbers

Five binaries. A quiet check after five seconds. A ten-second pause for legacy prefixes, a two-minute adoption window and a ten-minute initialization cap. A worktree-diff detail is still capped at 500 files and 256 KiB. None of these numbers is a benchmark; each one is a boundary that keeps a background process from becoming the loudest thing on the machine.

A snapshot is not valuable because it exists. It is valuable because the line between inherited state and work is drawn in the right place. The initialization window is where that line is decided: first for the files a checkout creates, then for everything the worktree does after it.