~ 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

Who vouched for a commit is found in process, not a git each merged pull

Merged
Merged chadtmiller.com asked to merge into main from chadtmiller.com/knotless:serve/vouched-in-process

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 one git rev-list per 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 getLastCommits on chadtmiller.com/knotless took 1.5s. Over 60 git rev-list processes 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 between against brought's walk over the same history, plus an empty range and the missing-revision errors. The existing what_merges_brought test now takes the range as its two ends. Builds and tests are left to CI. After deploy, the check is the first getLastCommits of the knotless repository: its duration, and no rev-list lines 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

Approved

This 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: between resolves its ends with rev_parse_single, so the {merged}^1 and {merged}^2 ends that brought builds 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.md doesn'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.

Approved

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.

Merged as 4b51cf3