PRs #2065, #2068, #2069 share a stale merge-base and carry 340+ unrelated files each

[carlos-alm]

Finding

PRs #2065, #2068, and #2069 (the 3 lowest-numbered open PRs from carlos-alm, as of 2026-07-12) all share the exact same merge-base commit with main (789b177fe193e4ad7ed88d59775edd42521987d3), which is roughly 116-121 commits behind current main. Each PR's actual diff footprint against that merge-base is far larger than its stated single-purpose title suggests:

PR	Title	Files changed vs merge-base	Insertions
#2065	fix(extractors): extract bare super(...) constructor calls as call edges	342	34,860
#2068	fix: persist deleted-export advisories so check survives purge ordering	347	35,944
#2069	fix(perf): resolve config once in withRepo to avoid double loadConfig	349	36,135

A real git merge origin/main attempt on #2068 produces 90+ conflicting files spanning the mirrored Rust/TS core (extractors, resolver, graph builder stages, complexity, roles classifier, etc.), not just the file(s) the PR's own description mentions.

Separately, PR #2065's branch (fix/issue-1929-bare-super-constructor-calls-are-never) is currently checked out in worktree .claude/worktrees/agent-aa949caa79f05c88f with 113 staged, uncommitted files — a similarly broad, unrelated-looking changeset (touching the same wide surface: Rust core, TS extractors, docs, scripts) that was never committed.

Why this blocks automated processing

An autonomous PR-merge loop was asked to resolve conflicts / address Greptile feedback / fix CI / merge the lowest-numbered of these 3 PRs. Attempting a blind, automated conflict resolution across 340+ files touching core resolver/extractor logic in both Rust and TypeScript is unsafe — there's no way to verify correctness of that scale of reconciliation without deep review, and a wrong resolution could silently reintroduce or break resolution-engine behavior (parity bugs, incorrect edges, etc.) that would be very hard to detect after the fact.

Suspected root cause

All 3 branches look like they were forked from a shared long-running integration/dev branch (not a clean point of main) and never resynced, rather than being small standalone fix branches as their titles imply. The identical merge-base across all three all but confirms a common ancestor branch.

Suggested next step

Needs human triage: for each of #2065/#2068/#2069, decide whether to (a) recreate the PR from a fresh branch off current main cherry-picking just the intended fix, (b) do a careful supervised merge/rebase, or (c) close as superseded if the intended fix already landed another way (as was the case for several other stale branches found during a recent /housekeep pass — see PR history around #2100 and issue #2099 for related cleanup context).

Found via

Autonomous PR-merge /loop run on 2026-07-12, while attempting to resolve conflicts on PR #2068 per user instruction to process the 3 lowest-numbered open PRs from carlos-alm/dependabot.

[carlos-alm]

Resolved via recreation (option a): #2065 → #2102, #2068 → #2103, #2069 → #2104. All three recreated from a clean branch off current main, cherry-picking/reapplying just the intended fix and verified with a native rebuild + tests. Original PRs closed as superseded.