[UI] Re-prime the stack preview when the status behind it changes - #39
Merged
Conversation
This was referenced Jul 26, 2026
DiffCommit/NumstatCommit passed --binary, which the branch-wide DiffAgainstBase never did. --binary is for producing appliable patches: it makes git inline a base85 "GIT binary patch" literal for every changed binary file. A 3KB blob expands to 123 lines; a few hundred KB is enough to exhaust the viewer's 20k-line cap and leave the preview pane showing nothing but base85. It also mis-colours: git's base85 alphabet includes + and -, so the diff body styler paints scattered literal lines as additions and deletions. Dropping the flag yields the usual one-line "Binary files a/x and b/x differ", matching DiffAgainstBase. The numstat path is unaffected — it already reported binary files as Binary with zero counts, so the file index still renders them as "binary". Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> ct-stack-id: 7e62f7d8
Refreshing with the preview pane open left it on "loading diff…" forever. applyStackStatus drops the per-commit diff cache — correctly, since a restack or amend can move SHAs out from under it — but nothing re-issued the fetch, so the pane went on looking up a key that would never be filled. Only nudging the cursor onto another commit brought it back. Pressing r, the most natural thing to do while reading a diff, was enough to hit it. The four status-bearing results now re-kick the cursored commit's fetch through ensureSplitDiff, which no-ops unless the preview is actually on screen. Doing it at the message handler rather than inside the apply helpers keeps them free of command plumbing and covers submit, restack and merge — restack lands a status whose SHAs are all new, so it misses the cache the same way a refresh does. A real restack also drops the cache outright now, so a resurrected SHA cannot serve a pre-restack patch. The dry run leaves it alone; it only renders a plan. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> ct-stack-id: bdeaacb1
KCaverly
force-pushed
the
ct/diff_view/7e62f7d8
branch
from
July 26, 2026 19:23
de84f37 to
228e192
Compare
KCaverly
force-pushed
the
ct/diff_view/bdeaacb1
branch
from
July 26, 2026 19:23
9a60c33 to
2a3913f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refreshing with the preview pane open left it on "loading diff…" forever.
applyStackStatus drops the per-commit diff cache — correctly, since a
restack or amend can move SHAs out from under it — but nothing re-issued
the fetch, so the pane went on looking up a key that would never be filled.
Only nudging the cursor onto another commit brought it back. Pressing r,
the most natural thing to do while reading a diff, was enough to hit it.
The four status-bearing results now re-kick the cursored commit's fetch
through ensureSplitDiff, which no-ops unless the preview is actually on
screen. Doing it at the message handler rather than inside the apply
helpers keeps them free of command plumbing and covers submit, restack and
merge — restack lands a status whose SHAs are all new, so it misses the
cache the same way a refresh does.
A real restack also drops the cache outright now, so a resurrected SHA
cannot serve a pre-restack patch. The dry run leaves it alone; it only
renders a plan.
Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
Stack (bottom → top):