V0.11.2/chore

[gimlichael]

This pull request lets a clean feature branch with no upstream tracking proceed through the reviewed first-publication flow. Execution publishes the approved branch to the resolved GitHub remote, establishes tracking, and verifies the result before creating the PR.

First publication:

• Preview a normal push to origin or the sole GitHub remote under the current branch name, including upstream tracking when it is absent.
• Bind tracking intent into the approval plan and verify the remote, branch, and tracking state after the push before writing PR metadata.
• Keep ambiguous remotes, partial tracking, and mismatched branch names fail-closed, with regression coverage for first publication and existing remote branches.

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Updates pull request workflow to handle untracked branches.

The PR should not merge until first publication verifies the repository that will actually receive the push.

Findings

1.  Push targets a different repository ▶

Fix with agent prompt

### Issue 1
skills/git-remote-pr/scripts/prepare-pr.ps1:34
If `origin` has a `pushurl` pointing to repository B while its `url` points to repository A, preparation shows A as the PR head, but `git push origin` publishes the branch to B. The SHA check against A fails only after the unintended push. Verify the effective push destination before approving first publication, or reject a remote whose push destination differs from the resolved head repository.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR enables a clean branch without upstream tracking to be previewed, published with tracking, and used as a PR head. It also binds that tracking write to approval and adds first-publication regression cases.

• The publication path needs to verify the remote’s effective push destination, not only its read URL.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Clean branch without tracking] --> B[Resolve head from remote URL]
  B --> C[Preview and approve]
  C --> D[Push with upstream tracking]
  D --> E[Verify remote SHA and tracking]
  E --> F[Create or update PR]

Loading

_{Reviews (1) · Last reviewed commit: "🔨 support first-push publication"}

[greptile-apps]

Push targets a different repository

If origin has a pushurl pointing to repository B while its url points to repository A, preparation shows A as the PR head, but git push origin publishes the branch to B. The SHA check against A fails only after the unintended push. Verify the effective push destination before approving first publication, or reject a remote whose push destination differs from the resolved head repository.

Knowledge Base Used: Remote pull request workflows

Prompt To Fix With AI

This is a comment left during a code review.
Path: skills/git-remote-pr/scripts/prepare-pr.ps1
Line: 34

Comment:
**Push targets a different repository**

If `origin` has a `pushurl` pointing to repository B while its `url` points to repository A, preparation shows A as the PR head, but `git push origin` publishes the branch to B. The SHA check against A fails only after the unintended push. Verify the effective push destination before approving first publication, or reject a remote whose push destination differs from the resolved head repository.

**Knowledge Base Used:** [Remote pull request workflows](https://app.greptile.com/geekle/-/custom-context/knowledge-base/codebeltnet/agentic/-/docs/git-remote-pull-requests.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.