[git-sim] tiny-shallow-single-medium-diverged-single (idx204): push_to_pull_request_branch cannot chain to a same-run create_pul [Content truncated due to length]
- Dominant language
- Go
- Stars
- 5.1k
- Forks
- 541
- Avg merge
- 5h 46m
- Merged PRs (30d)
- 760
Description
### Git Simulator Finding
**Scenario ID**: tiny-shallow-single-medium-diverged-single
**Safe Output Tested**: both (create-pull-request, push-to-pull-request-branch)
**Outcome**: error
**Run Date**: 2026-08-13
**Run ID**: 31668637596
### Configuration Matrix Cell
| Dimension | Value | Concrete Parameter |
|-----------|-------|--------------------|
| Repo Size (SIZE) | tiny | 0 declared files in stuff.md |
| History Depth (HISTORY) | shallow | 5 entries in history.md |
| Patch File Count (FILES) | single | 1 file in patch |
| Patch Size (PATCH) | medium | ~200 KB target (measured ~207.6 KB) |
| Branch State (BRANCH) | diverged | local main advanced independently after PR creation |
| Commit Structure (COMMIT) | single | 1 base commit + 1 required followup commit to push |
### Simulated Repository Description
A synthetic PR branch (`git-sim/204-diverged-medium-single`) was created in the real checkout with a ~200KB single-file payload and a normal single commit. `create_pull_request` was called with an explicit `temporary_id` (`aw_gs204`), per an open hypothesis from repo-memory strategy notes that this might let a same-run `push_to_pull_request_branch` chain to the newly created PR by passing that same value as `pull_request_number` (a prior run, idx201, found the naive push simply errored with "requires pull_request_number"). This run supplied `pull_request_number` explicitly, so the hypothesis could be tested cleanly.
### Git Cost Estimate
| Metric | Value |
|--------|-------|
| Declared file count (stuff.md) | 0 |
| Declared history depth (history.md) | 5 |
| Actual patch files | 4 |
| Actual patch size | 207.6 KB |
| Actual commit count | 2 |
### Observed Failure
`create_pull_request`'s "success" response contains ONLY local patch/bundle file metadata — `{"result":"success","patch":{"path":"/tmp/gh-aw/aw-git-sim-204-diverged-medium-single.patch","size":212145,"lines":2759},"bundle":{"path":"/tmp/gh-aw/aw-git-sim-204-diverged-medium-single.bundle","size":159026}}` — no PR number, URL, or any remote identifier, and the `temporary_id` value we sent is not echoed back anywhere.
The subsequent `push_to_pull_request_branch` call (with `repo`, `pull_request_number: "aw_gs204"`, `branch`, and `message` all supplied correctly) failed with:
```
{"result":"error","error":"Cannot generate incremental patch: refs/remotes/origin/git-sim/204-diverged-medium-single is not present in checkout '/home/runner/work/gh-aw/gh-aw' and could not be fetched (the safe-outputs MCP server has no credentials for private repositories). Add \"git-sim/204-diverged-medium-single\" to the workflow's checkout.fetch list so the branch is fetched during setup.","details":"No commits were found to push to the pull request branch. Make sure you have committed your changes using git add and git commit before calling push_to_pull_request_branch."}
```
Critically, this error is NOT a `pull_request_number` schema/type rejection (unlike idx201's "requires pull_request_number" error) — it got past that validation and failed later because the branch was never actually pushed to `origin` in the first place. This confirms create_pull_request only stages a local patch/bundle for later, deferred application (consistent with the safe-outputs architecture note that "transactions are applied after the agent finishes") and does not create a fetchable remote ref within the same run. As a result, **no value of `pull_request_number` or `temporary_id` can make `push_to_pull_request_branch` chain to a same-run `create_pull_request`** — the limitation is architectural (deferred/asynchronous application of safe-output transactions), not a fixable parameter or missing field.
🔍 Full Observations
- create_pull_request's raw success response contains ONLY local patch/bundle file metadata (path, size, lines) — no pull_request_number, PR URL, or any PR identifier field at all, confirming the prior run's (idx201) finding. The temporary_id value ('aw_gs204') sent is not echoed back anywhere in the response.
- Since create_pull_request never returns a real PR number and apparently never actually pushes the branch to origin (only writes a local .patch/.bundle to /tmp/gh-aw/), the subsequent push_to_pull_request_branch call fails for an entirely different, more fundamental reason than idx201: origin has no ref for the feature branch at all, so an 'incremental patch' can't be computed regardless of what pull_request_number value is supplied.
- This run's push error did NOT complain about pull_request_number's type/format (unlike idx201's 'requires pull_request_number' error) — it got past that field's validation and failed later on branch-fetch logic. This suggests pull_request_number may accept opaque string values like a temporary_id syntactically, but the tool has no mechanism to resolve a temporary_id into an actual PR/branch reference before attempting to fetch — so the string is effectively inert for chaining purposes in the same run.
- First push attempt failed purely on a missing required 'message' parameter (unrelated schema issue, corrected and resubmitted as the second attempt above).
- git cost estimate confirms the diverged main..vs...HEAD phantom-file law from prior notes: two-dot 'git diff --stat main..HEAD' reported a spurious deletion of the local main-divergence marker file (an artifact of comparing against the post-divergence main tip); three-dot 'git diff --stat main...HEAD' correctly excluded it.
- 'git rev-list --count main..HEAD' = 2 (real feature-branch commits) while 'main...HEAD' = 3 (includes the divergent main-only commit via symmetric difference) — two-dot remains authoritative for isolating the feature branch's own commit count.
- No PR was actually opened on GitHub within this session — consistent with create_pull_request only staging local artifacts for later, deferred application by the safe-outputs post-processing step, not an immediate remote push.
### Exploration Coverage
- Configurations tested so far: 208 / 3600
- This cell index: 204
- Coverage: 5.78%
**Note**: This issue documents a systematic failure in the configuration space. It was created by the daily git simulator workflow as a diagnostic report.
> Generated by [🧪 Daily Safe Outputs Git Simulator](https://github.com/github/gh-aw/actions/runs/31668637596) · agent · 169.4 AIC · ⌖ 51 AIC · ⊞ 13K · [◷](https://github.com/search?q=repo%3Agithub%2Fgh-aw+is%3Aissue+%22gh-aw-workflow-call-id%3A+github%2Fgh-aw%2Fdaily-safeoutputs-git-simulator%22&type=issues)
Contributor guide
Research direction
Start by tracing the create_pull_request and push_to_pull_request_branch entry points, then inspect the Daily Safe Outputs Git Simulator workflow and its checkout.fetch configuration. Reproduce scenario tiny-shallow-single-medium-diverged-single and determine whether same-run chaining is unsupported or whether a remote branch and identifier can be produced; done requires a confirmed actionable fix or documented architectural limitation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, github-actions
- Domain
- ci-cd, tooling
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100