Objective
Add a sanity check that detects an implausible commit range (e.g., tens of thousands of commits for what should be a one- or few-commit branch) in a shallow checkout, and fail fast with a clear warning instead of proceeding to synthesize a potentially huge/incorrect rewrite commit.
Context
In a shallow checkout (default fetch-depth: 1), origin/<base> has no traversable ancestry, so git rev-list --parents --topo-order --reverse <origin/base>..HEAD cannot exclude anything and returns essentially the entire repository history (e.g., 61,008 commits for a repo with ~61k commits on main). This large range then trips merge-commit detection and forces the rewrite path (linearizeRangeAsCommit), which can produce an incorrect result (see companion issue about linearizing against the correct base). Detecting the implausible range early is far cheaper than synthesizing a multi-MB payload only to have it fail a size gate.
Suggested Approach
- Locate the code in
actions/setup/js/git_helpers.cjs / create_pull_request.cjs that computes the commit range via git rev-list --parents --topo-order --reverse.
- After computing the range/count, compare it against a reasonable threshold (e.g., configurable, default maybe 50-100 commits) or compare against the known number of commits the agent's branch should have.
- If the range size is implausible for a shallow checkout, emit a clear warning/error log (e.g., "Shallow checkout produced an implausible commit range (N commits); consider increasing fetch-depth") and abort the push attempt (or fall back to requiring a deeper fetch) rather than proceeding to rewrite.
- Add a log message referencing the shallow-checkout condition so users can diagnose and apply the
fetch-depth workaround.
- Add tests simulating a shallow checkout with a large synthetic commit range to verify the new guard triggers.
Files to Modify
actions/setup/js/git_helpers.cjs
actions/setup/js/create_pull_request.cjs
- Relevant test files
- Documentation: mention the
fetch-depth workaround in relevant checkout/safe-outputs docs
Acceptance Criteria
Generated by 📋 Plan Command · aut00 · 18.7 AIC · ⌖ 5.78 AIC · ⊞ 6.8K · ◷
Comment /plan to run again
Objective
Add a sanity check that detects an implausible commit range (e.g., tens of thousands of commits for what should be a one- or few-commit branch) in a shallow checkout, and fail fast with a clear warning instead of proceeding to synthesize a potentially huge/incorrect rewrite commit.
Context
In a shallow checkout (default
fetch-depth: 1),origin/<base>has no traversable ancestry, sogit rev-list --parents --topo-order --reverse <origin/base>..HEADcannot exclude anything and returns essentially the entire repository history (e.g., 61,008 commits for a repo with ~61k commits on main). This large range then trips merge-commit detection and forces the rewrite path (linearizeRangeAsCommit), which can produce an incorrect result (see companion issue about linearizing against the correct base). Detecting the implausible range early is far cheaper than synthesizing a multi-MB payload only to have it fail a size gate.Suggested Approach
actions/setup/js/git_helpers.cjs/create_pull_request.cjsthat computes the commit range viagit rev-list --parents --topo-order --reverse.fetch-depthworkaround.Files to Modify
actions/setup/js/git_helpers.cjsactions/setup/js/create_pull_request.cjsfetch-depthworkaround in relevant checkout/safe-outputs docsAcceptance Criteria
fetch-depthworkaround for large monorepos