`push_to_pull_request_branch` generates a bad patch when triggered via an `issue_comment` event on a PR

[strawgate]

Observed on elastic/ai-github-actions#169 (comment)

Agent added one follow-up commit, but generated patch started with [PATCH 1/2] for a commit already on the PR branch, then [PATCH 2/2] for the new commit.

In safe_outputs, we checked out origin/main-ef3ad89c0dd0de53 and git am failed on patch 1 (already exists in index / patch does not apply), so patch 2 never applied.

Likely cause: when refs/remotes/origin/ is not detected at patch-generation time, generate_git_patch.cjs falls back to merge-base(origin/main, ), which can include already-present branch history.

Expected for push_to_pull_request_branch: always generate incremental patch from origin/..HEAD (fetch that ref explicitly); if unavailable, fail clearly instead of merge-base fallback.

Suggested fix:
In generate_git_patch.cjs, add a strict mode for push_to_pull_request_branch:

• explicitly fetch origin :refs/remotes/origin/
• generate patch from origin/..HEAD
• no merge-base fallback in this mode

Keep current fallback behavior for create_pull_request only

[dsyme]

@strawgate Thank you! Your report was excellent and helped find the bug.

It's a difficult area and in #18160 I've added what is hopefully better testing and checking of Git behaviour, and there is a fix there not to bundle up all the commits - exactly as you suggest.

[dsyme]

Fixed in #18175 (we hope, testing is hard for theis area)