Problem
When using push_to_pull_request_branch to push incremental changes to an existing PR branch, the handler fails with a CONFLICT (add/add) merge conflict if the target file already exists on the branch from a previous push.
How to reproduce
- Configure a workflow with
push_to_pull_request_branch that targets an existing PR branch.
- Run the workflow. The agent creates a new file (e.g.
docs/findings.md). The handler applies the patch successfully and pushes to the PR branch.
- Run the workflow again for the same PR. The agent again produces a patch that creates the same file, because the agent workspace is checked out from the base branch where the file does not exist. The patch contains
create mode 100644 / new file mode 100644 / index 0000000...
- The handler checks out the PR branch (where the file already exists from step 2), then runs
git am --3way with the patch.
git am sees "create new file" but the file already exists → CONFLICT (add/add) → handler fails.
The same failure occurs when the agent produces a multi-commit patch series where earlier commits are already applied on the branch.
Root cause
The patch is generated against the base branch state (where the file does not exist), but applied to the PR branch state (where the file was created by a previous push). git am cannot reconcile "create from /dev/null" with an existing file.
Expected behavior
push_to_pull_request_branch should successfully apply changes to an existing PR branch, even when the target file was created by a previous push to that same branch.
Suggested solutions (any of these would work)
-
Diff against PR branch HEAD, not base — Before applying, compute the incremental diff between the patch final tree and the current PR branch HEAD. Apply only the delta.
-
Extract final file state from the patch and write directly — Instead of replaying commits via git am, materialize the final file contents from the patch, write them to the working tree, and create a single merge commit. This avoids the replay-history problem entirely.
-
Skip already-applied commits — Before git am, check if each commit in the patch series is an ancestor of the PR branch HEAD (by commit hash or by patch-id). Skip commits that are already applied.
-
Fall back on git am conflict — If git am --3way fails with an add/add conflict, abort the am session, extract the intended file contents from the patch, write them directly, and commit. This preserves the current happy path while adding resilience for the incremental push case.
Impact
Any workflow that runs multiple times and pushes to the same PR branch will fail on the second run onward, because the handler cannot push incremental updates to a file it already created.
Problem
When using
push_to_pull_request_branchto push incremental changes to an existing PR branch, the handler fails with aCONFLICT (add/add)merge conflict if the target file already exists on the branch from a previous push.How to reproduce
push_to_pull_request_branchthat targets an existing PR branch.docs/findings.md). The handler applies the patch successfully and pushes to the PR branch.create mode 100644/new file mode 100644/index 0000000...git am --3waywith the patch.git amsees "create new file" but the file already exists →CONFLICT (add/add)→ handler fails.The same failure occurs when the agent produces a multi-commit patch series where earlier commits are already applied on the branch.
Root cause
The patch is generated against the base branch state (where the file does not exist), but applied to the PR branch state (where the file was created by a previous push).
git amcannot reconcile "create from/dev/null" with an existing file.Expected behavior
push_to_pull_request_branchshould successfully apply changes to an existing PR branch, even when the target file was created by a previous push to that same branch.Suggested solutions (any of these would work)
Diff against PR branch HEAD, not base — Before applying, compute the incremental diff between the patch final tree and the current PR branch HEAD. Apply only the delta.
Extract final file state from the patch and write directly — Instead of replaying commits via
git am, materialize the final file contents from the patch, write them to the working tree, and create a single merge commit. This avoids the replay-history problem entirely.Skip already-applied commits — Before
git am, check if each commit in the patch series is an ancestor of the PR branch HEAD (by commit hash or by patch-id). Skip commits that are already applied.Fall back on
git amconflict — Ifgit am --3wayfails with an add/add conflict, abort the am session, extract the intended file contents from the patch, write them directly, and commit. This preserves the current happy path while adding resilience for the incremental push case.Impact
Any workflow that runs multiple times and pushes to the same PR branch will fail on the second run onward, because the handler cannot push incremental updates to a file it already created.