feat: list related commits under every thread by younes-io · Pull Request #1069 · dev-null-sh/dev-null.sh

younes-io · 2026-10-23T19:34:03Z

what this does

When you open a commit, the page now ends with up to three commits from other threads that talk about the same thing. They look like any other commit cards. You can open, star, and report them, and j and k walk into them from the thread.

why

People post the same feelings and the same wins a few days apart and never see each other. A thread about a brutal day sits next to "I'm tired boss" and "too tired" and nobody knows. Search can find them, but only if you think to search. This puts them one scroll below the thread.

before and after

Taken on a local instance. The post bodies are real public posts from dev-null.sh, attributed to fake accounts. The vectors are real too. I ran php artisan commits:embed so every post went through text-embedding-3-small, and the last post was made through the composer and got its vector from the normal EmbedCommit job.

before

The thread ends after its replies.

after

The same thread, followed by the three nearest commits from other threads.

another thread

A post about side projects, with three neighbours.

a post made during the run

"Exhausted after a week of on-call", typed into the composer. The queue worker gave it a vector, and its rail lists Nora's "most exhausting work day" thread from the before and after images above.

nothing nearby

A post with no neighbour inside the cutoff shows no rail at all.

how it picks them

the query

It uses the vectors EmbedCommit already stores for search. One pgvector query per page, no OpenAI call when reading. Two commits count as related when their cosine distance is 0.60 or less.

the cutoff

I did not know what a good cutoff was, so I measured it on 281 real posts.

Under 0.45, pairs are near duplicates.
Between 0.45 and 0.60, they share a topic.
Past 0.60, they stop making sense together.

I started at 0.45 and the rail was empty almost everywhere, so I moved it to 0.60. Matches near 0.60 are "same subject", not "same sentence". If the rail turns out too chatty or too quiet in production, MAX_DISTANCE in RelatedCommitsQuery is the one number to change.

what it leaves out

The rail only shows what you could find through search.

Nothing pending, deleted, muted, or across a block.
Nothing from the thread you are reading.
Only top-level commits.
No rail when nothing qualifies or the commit has no vector yet. There is no empty state.

loading

The thread renders first and the client fetches the rail afterwards, the way /search works. The signed API has the same list at GET /api/v1/commits/{commit}/related.

checks

Browser-checked on an isolated instance, once with hand-set vectors at known distances and once with real vectors from commits:embed.
The full suite passes at 100% coverage with Pint, Rector, tsc, lint, and the node tests.
PHPStan has the same seven pre-existing errors as production.

not in this PR

While testing I hit an unrelated bug where a second approved post within an hour 500s without a queue worker. Filed as Second approved commit 500s while CheckUserLevel still holds its unique-job lock #1066.
A composer hint ("you already said this") could use the same query later.

Summary by CodeRabbit

New Features
- Commit pages now show a “Related commits” section with up to three similar commits from other threads.
- Suggestions exclude pending commits and commits hidden by visibility restrictions or mute settings. The section is omitted when no close matches are available.

A unit vector in the plane of axes 0 and 1 whose distance to the one-hot vector at index 0 is exactly the given value. Signed-off-by: Younes <git@younes.io>

RelatedCommitsQuery returns up to three top-level commits from other threads whose embedding is within 0.45 cosine distance of the given commit, nearest first, scoped like search by visibility, mutes and blocks. The source vector is read in a subselect so it never leaves the database. Signed-off-by: Younes <git@younes.io>