fix(core): use header counts for hunkLineRange so context lines are in range#244
fix(core): use header counts for hunkLineRange so context lines are in range#244aldevv wants to merge 1 commit intomodem-dev:mainfrom
Conversation
…n range
hunkLineRange used additionLines/deletionLines (count of '+' / '-' rows)
as the per-side extent. Pierre exposes those as the change counts only —
the per-side header total (which includes context) is in additionCount /
deletionCount. With many context rows around few changes the additions-only
extent produced range = [start, start], so:
- Comments anchored past leading context (resolved by firstCommentTargetForHunk
walking hunkContent) fell outside the hunk's range, annotationOverlapsHunk
returned false, getAnnotatedHunkIndices left the hunk unflagged, and the
hunk silently disappeared from buildAnnotatedHunkCursors. } / { skipped
it during comment navigation.
- findHunkIndexForLine returned -1 for context lines, even when those lines
belong to a hunk in the diff stream.
Fix: switch hunkLineRange to additionCount / deletionCount and consolidate
the duplicate copy in agentAnnotations.ts to a single import. Add a
regression test with one addition surrounded by context that fails under
the old additions-only extent.
Greptile SummaryThis PR fixes a silent comment-navigation regression where hunks containing few changes surrounded by many context lines were dropped from
Confidence Score: 5/5Safe to merge — the change is a targeted two-field swap with a matching regression test and no new surface area. The fix is minimal and well-scoped: one function, two field names changed, a stale duplicate removed, and a regression test that exercises the exact failure scenario described in the PR. The additionCount/deletionCount fields are documented in the pierre Hunk type, and the existing test suite already exercises the non-degenerate path. No logic outside of hunkLineRange was touched. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["hunkLineRange(hunk)"] --> B{"Before fix"}
A --> C{"After fix"}
B --> D["newEnd = additionStart + additionLines − 1\n(only '+' rows)"]
C --> E["newEnd = additionStart + additionCount − 1\n(context + '+' rows)"]
D --> F["Range collapses: [28, 28]\nfor 16-line hunk with 1 addition"]
E --> G["Range correct: [28, 44]\nfor 16-line hunk with 1 addition"]
F --> H["annotationOverlapsHunk → false\nfor comments past leading context"]
G --> I["annotationOverlapsHunk → true\nall comments in hunk found"]
H --> J["Hunk silently dropped from\ngetAnnotatedHunkIndices /\nbuildAnnotatedHunkCursors"]
I --> K["All 4 cursors present\n} / { navigation works"]
Reviews (1): Last reviewed commit: "fix(core): use header counts for hunkLin..." | Re-trigger Greptile |
User-visible:
}/{and--next-commentsilently skip comments — visiting some, missing others. Repros whenever a comment is anchored on a line past the leading context of its hunk.Steps to reproduce (on
main)hunk diff <range>on a diff that contains a hunk where the actual+/-line sits past leading context — e.g. a header like@@ -28,20 +28,17 @@whose first added line is around line 40.firstCommentTargetForHunk):}(or runhunk session navigate --repo <repo> --next-comment) repeatedly.Fix:
hunkLineRangenow uses the per-side header total (additionCount/deletionCount, includes context), not the addition/deletion-only count, so comment-anchor lines fall inside the hunk's range and the hunks make it into the navigation cursor list. Also consolidates the duplicated copy inagentAnnotations.tsinto a single import, and adds a regression test.No user-facing docs or workflows change.
Fixes #235.