~ knotless Search/
↑↓ move↵ open⇧↵ all results

chadtmiller.com/knotless

git that lives in your Atmosphere account

knotless.dev
1 collaborator

knotless 0.13.0 Latest 2 packages, 1 image

1
10

repo commit reads the repository once, a round trip less

Merged
Merged chadtmiller.com asked to merge into main from chadtmiller.com/knotless:client/commit-reads-once

knotless repo commit read the repository's record and refs twice before committing. It now reads them once, so every commit made without a checkout waits for one round trip to the PDS less. One function changes; a quick look is enough.

Claude Fable 5.2

What changes

commit() in crates/knotless/src/commit.rs builds its first attempt on the snapshot Remote::locate read. Before, it kept only the remote from locate, dropped the snapshot, and read another as the loop began. A replay after a lost race still reads a fresh one. The CLI's repo commit and the MCP tool repo_commit both go through this function.

Why

docs/reference/performance.md says a warm repo commit takes two round trips: the snapshot and one applyWrites. Running the bench at several round-trip times showed three: its median grew by 3.04 times the latency added, where git push grew by 2.03 and git fetch by 1.01. The third was the second read.

How it was checked

crates/knotless/examples/bench.rs against the npm reference PDS, release build, on an M1 Pro, with no connection cost counted, at 0 and 200 ms of round-trip time:

repo commit, p500 ms200 msRound trips
Before251 ms859 ms3.04
After267 ms659 ms1.96

Before is the median of two runs at each latency, after one run at each, with other builds going on the machine, which is why its 0 ms figure is the higher.

No test is added. The suite's commits go through the first attempt, and library.rs's race, which asserts attempts > 1, through the replay, so both arms of the new match are reached. check and test are left to CI: nothing but the bench was run here.

Shortcomings

  • No test holds the count of round trips. One would need a proxy that counts requests in the harness, which does not exist.
  • The first attempt's snapshot is now read before the session is looked up and the commit signed, so it is a little older when the push goes out, by a token refresh at most. The claim pins the generation it read, so a branch that moved in between costs a replay, as any lost race does, and never a wrong write.
Approved

commit() now uses the snapshot Remote::locate already read for its first attempt, and reads a fresh one only on a replay. I found nothing wrong.

  • locate returns the snapshot of the remote it ends on, after following moves, so the first attempt pairs the right remote with its snapshot.
  • The snapshot is a little older by the time of the push, as the body says. The claim pins the generation it read, so a branch that moved costs one replay and not a wrong write.
  • The gateway path returns before the snapshot is used, so its behavior is unchanged.
  • The change file is present, as check requires.
  • I read the diff and the code around it but ran no tests. I did not check docs/reference/performance.md.
Merged as dc26a21