fix: compare a repo against its siblings off the render thread

[matt-edmondson]

Fixes #414

What was wrong

SwitchPage and RefreshPage called UpdateSimilarRepos inline on the ImGui render thread. For each sibling repository that is two git ls-files subprocesses, a File.ReadAllText of every shared file from both working trees, and a whole-file DiffPlex pass — on every repo click, not once at startup. FetchRepo, PullRepo, PushRepo and Clone all wrap their git calls in a Task for exactly this reason; this path never got the same treatment, and it sits on the app's most frequent interaction.

What changed

Backgrounded. CompareSiblingsAsync snapshots the sibling list on the calling thread — so the task never enumerates Options.Repos while the UI can change it, and the unsupported-repository throw stays where it is observable — then does the work on a Task which it returns, so a caller that cares can wait for it. UpdateSimilarRepos is now one line handing it Options.Repos and QueueLog.

Published atomically. SimilarRepoDiffs moved from a fill-in-place Dictionary to a swappable snapshot behind IReadOnlyDictionary. A reader on the render thread sees the previous answer or the next one, never a half-built dictionary.

Newest run wins. Clicking through several repositories leaves that many comparisons in flight and they do not finish in the order they started, so each run carries a token and only the newest may publish. Without this, backgrounding alone would let a slow earlier run overwrite the answer for the repository the user is now looking at.

Cheaper, not just later. The base repository's tracked-file list is read once per run rather than once per sibling. Across N siblings that is N + 1 calls to git ls-files where there were 2N. I deliberately did not add a persistent per-repo cache as the triage suggested: its invalidation points (fetch, pull, commit, propagate, clone) are spread across the file, and getting one wrong shows a stale comparison rather than a slow one. Per-run is the half of that benefit with no staleness at all — say the word if you want the persistent cache too and I'll do it as its own change.

No stale answer on screen. Requesting a comparison drops the previous one, since it describes whichever repository was selected before. The triage asked for a pending state rather than last frame's answer, so while a run is outstanding the panel draws Comparing repositories.... The three panels that render a comparison are mutually exclusive, so that decision is made once where they are dispatched rather than repeated at the top of each.

Render paths ask instead of indexing. Three sites indexed SimilarRepoDiffs[...][...] directly, which was safe only because the dictionary was always fully populated before the frame. RefreshPage keeps CompareRepo/CompareFile across a refresh, so those would now throw during the pending window — they go through FindDiff, whose nullable result the two divider callbacks pass straight into ShowDiffLeft/ShowDiffRight, which already guard it. RefreshFileDiff likewise tolerates a comparison publishing between the frame deciding to draw a file and the apply button being pressed.

Testing

17 tests in SimilarReposTests, 82 total (was 65), 79 passing and the same 3 skipped for the missing git-lfs. No existing test changed.

Per CLAUDE.md's convention, the parts with a rule in them are plain methods drivable without a live ImGui context — PairSiblings, CompareSiblingsAsync, DiffAgainstAll, FindDiff, RefreshFileDiff and the request/publish pair on GitRepository — driven against throwaway repositories the way GitCliTests drives GitCli.

Verified the tests pin the new behaviour: reverting the request/publish guard to the old fill-in-place semantics (last writer wins, previous answer retained) fails RequestingAComparisonClearsTheLastAnswerAndReportsPending, ASupersededComparisonCannotPublish and ALateComparisonCannotOverwriteAnAlreadyPublishedNewerOne, and restoring it returns the suite to green.

On the coverage gate

The first push failed SonarCloud's quality gate at 34.7% new-code coverage against a required 80%, because most of the change sat in the ImGui layer this repo does not unit-test. Lifting those rules into testable methods is what the third commit does, and the gate now passes — at 80.0%, exactly on the bar. My own line-based measurement said 83.6%; Sonar counts branches as well as lines, which is where the difference comes from, and its number is the one that counts.

Worth knowing for whatever lands next here: there is no headroom. The 13 lines still uncovered are the render sites themselves — the two divider callbacks, the one-line UpdateSimilarRepos, the pending branch at the panel dispatcher, and ShowComparedFile's null guard — and this repo does not unit-test the ImGui layer by design. Any further UI-side addition to this diff would drop it under the gate.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JnRJuBBrg4LLgytqvkRmLJ

[matt-edmondson]

Not fixing this one — readonly does not compile here.

The field is reassigned outside the constructor, through Volatile.Write(ref similarRepoDiffs, …) in both RequestSimilarRepoDiffs and TryApplySimilarRepoDiffs. That needs a writable ref, so marking it readonly gives three CS0192: A readonly field cannot be used as a ref or out value (except in a constructor), which I confirmed by building it.

The whole point of the field being reassignable is that the comparison is published as one whole dictionary rather than filled in place, so a reader on the render thread never sees a half-built one.

The other findings in this review are fixed in 1a85981.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
7 New issues
0 Accepted issues

Measures
0 Security Hotspots
80.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud