diffctx 1.15.0, a private infrastructure repo, range of 18 changed files.
diffctx listed 14 and silently omitted 4. The omitted set is exactly the substantive work of the range; the retained set is mostly bot noise.
Dropped — all multi-line, hand-written changes:
- a CronJob manifest (moved a staging volume off the node's root disk)
- a Namespace manifest (added a Pod Security exception)
- a PrometheusRule manifest (added an alerting rule)
- a database Cluster manifest (changed backup retention)
Kept: 9 of the 14 are one-line image-tag bumps written by an automated image updater, each a single changed line of the form tag: main-<sha>.
So a reviewer handed this context sees nine bot tag bumps and none of the four changes a human made, with no indication anything is missing.
Not the .gitignore negation bug (#193). Checked: git check-ignore -v reports none of the four as ignored, there is no .diffctx/ignore, and the repo's two negation patterns match nothing here.
Not a path exclusion either. The decisive test: run diffctx on a narrow range containing only two of the dropped files. Both appear normally. They vanish only when they compete with the rest of the range.
That leaves selection ranking. Whatever orders candidates prefers many tiny files over fewer substantive ones once the range is mixed — which inverts what the tool is for, because the bot bumps are precisely the changes a reviewer never needs to read.
Two things that would make this survivable even if the ranking stays:
- Say what was dropped. The output carries a "withheld by exclusion policy" line for policy exclusions; there is no equivalent for budget or ranking drops, so an incomplete context is indistinguishable from a complete one. A reviewer can compensate for a known omission and cannot compensate for an invisible one.
- The range's title was taken from the last commit, which was a bot commit (
build: automatic update of ...). The header therefore describes the range by the least meaningful thing in it, compounding the same problem.
Repro shape: any repo where an image-updater bot commits between human commits — i.e. any GitOps-style repo — then diffctx . --diff <before-human-work>..HEAD.
Expected: either substantive files rank above single-line bot bumps, or the output states plainly that N files were dropped and names them.
diffctx 1.15.0, a private infrastructure repo, range of 18 changed files.
diffctx listed 14 and silently omitted 4. The omitted set is exactly the substantive work of the range; the retained set is mostly bot noise.
Dropped — all multi-line, hand-written changes:
Kept: 9 of the 14 are one-line image-tag bumps written by an automated image updater, each a single changed line of the form
tag: main-<sha>.So a reviewer handed this context sees nine bot tag bumps and none of the four changes a human made, with no indication anything is missing.
Not the
.gitignorenegation bug (#193). Checked:git check-ignore -vreports none of the four as ignored, there is no.diffctx/ignore, and the repo's two negation patterns match nothing here.Not a path exclusion either. The decisive test: run diffctx on a narrow range containing only two of the dropped files. Both appear normally. They vanish only when they compete with the rest of the range.
That leaves selection ranking. Whatever orders candidates prefers many tiny files over fewer substantive ones once the range is mixed — which inverts what the tool is for, because the bot bumps are precisely the changes a reviewer never needs to read.
Two things that would make this survivable even if the ranking stays:
build: automatic update of ...). The header therefore describes the range by the least meaningful thing in it, compounding the same problem.Repro shape: any repo where an image-updater bot commits between human commits — i.e. any GitOps-style repo — then
diffctx . --diff <before-human-work>..HEAD.Expected: either substantive files rank above single-line bot bumps, or the output states plainly that N files were dropped and names them.