chadtmiller.com/knotless
git that lives in your Atmosphere account
Who vouched for a commit is found in process, not a git each merged pull
MergedThis replaces one git rev-list process per merged pull with an in-process gix walk (Objects::between). The mirror is opened once and the walk runs under spawn_blocking. I found nothing that must change.
- Revision syntax:
betweenresolves its ends withrev_parse_single, so the{merged}^1and{merged}^2ends thatbroughtbuilds for merges recorded without a base still resolve. - Failed ranges: a range that errors, or a mirror that won't open, still returns an empty set and is not cached, so it is retried later as before.
- Mirror opening:
objects::open(&git.dir)is how other call sites in the crate open the mirror. - Docs:
docs/design/serve.mddoesn't describe this path.
I didn't run the build or tests; the pull leaves them to CI. The new test covers between against brought's walk, an empty range and the missing-revision errors. It doesn't run the ^1/^2 form through between. The brought unit test only checks the strings it builds.
The new commit fixes the type of people in vouched to Vec<(String, Option<Range>)>. That matches the Range = (String, String) alias and the unzip into Vec<Option<Range>> at web.rs:1163, so the type now agrees with the brought change. My earlier approval stands, and I found nothing new to ask for. I didn't run the build or tests. The test and check workflows were still queued when I looked, so wait for them before it lands.
8 passed, 2 skipped
What changes
The pages credit a commit to an account whose pull brought it in. Working out which commits each merged pull brought in now walks history inside knotless-serve (
Objects::between, over gix), with the mirror opened once for all of a repository's merged pulls, off the async threads. It used to start onegit rev-listper merged pull, all at the same time. The results are still kept per process once found, and a range whose commits the mirror lacks is still looked for again next time.Why
On prod at 17:07, one
getLastCommitson chadtmiller.com/knotless took 1.5s. Over 60git rev-listprocesses in its trace each took 1.1 to 1.2s, because they all ran at once against one mirror, one for every merged pull. The cache lives in the process, so this happens again after every deploy, and for every repository with many merged pulls, on its first commit view, tree or log. In process, each squash merge's range is one commit, a walk of a handful of objects.How it was checked
A new test checks
betweenagainstbrought's walk over the same history, plus an empty range and the missing-revision errors. The existingwhat_merges_broughttest now takes the range as its two ends. Builds and tests are left to CI. After deploy, the check is the firstgetLastCommitsof the knotless repository: its duration, and norev-listlines in its trace.Shortcomings
The cache still lives in the process, so a deploy still walks every merged pull once. That cost is now in-process and small, but it grows with the number of merged pulls.
🤖 Generated with Claude Code