Add --push option to forge pr create - #156
Conversation
There was a problem hiding this comment.
Pull request overview
Adds an opt-in --push flag to forge pr create, pushing the head branch and configuring upstream tracking before PR creation.
Changes:
- Adds reusable
git.PushBranchfunctionality. - Handles push failures.
- Adds Git and CLI tests.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
internal/git/git.go |
Implements branch pushing. |
internal/git/git_test.go |
Tests push behavior and validation. |
internal/cli/pr.go |
Integrates the --push flag. |
internal/cli/pr_test.go |
Tests successful and failed pushes. |
internal/cli/pr_checkout_test.go |
Extends the PR service mock. |
Suppressed comments (2)
internal/cli/pr.go:305
--headis also allowed to be a remote-qualified value such asowner:featurefor GitHub (the value is passed directly togithub.NewPullRequest.Headingithub/prs.go:199). Passing that whole value toPushBranchconstructsrefs/heads/owner:feature, which is not a valid local Git ref, soforge pr create --head owner:feature --pushalways fails before the PR can be created. Extract the local branch portion for the push while retaining the original qualified value inCreatePROpts.Head.
if err := git.PushBranch(cmd.Context(), "", resolve.RemoteName(), flagHead); err != nil {
internal/cli/pr.go:305
- This pushes to the selected remote but still sends the bare
flagHeadto the forge API. That breaks fork PRs when the remote's push target differs from the repository being resolved (for example-R upstream/repo --remote fork, or a remote with apushurl): GitHub requires the head as<fork-owner>:<branch>, so the API looks forfeaturein the upstream repo even though it was just pushed to the fork. Derive the local branch and pushed remote owner and pass the qualified head, or explicitly reject this cross-repository combination.
if err := git.PushBranch(cmd.Context(), "", resolve.RemoteName(), flagHead); err != nil {
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Addressed both suppressed findings. Qualified heads now push only the local branch while preserving |
andrew
left a comment
There was a problem hiding this comment.
Requesting changes for two fork-handling issues:
OWNER:BRANCHonly supplies usable source metadata to GitHub and Gitea. GitLab receives it as a literalsource_branch, while Bitbucket receives it assource.branch.namewithout a source repository, so the push succeeds before PR creation fails.- Requiring the push repository name to match the base repository rejects renamed GitHub forks, although GitHub identifies a cross-repository head by its owner and branch within the fork network.
Please add provider-specific source repository handling or reject unsupported fork pushes, relax or replace the repository-name check for qualified GitHub heads, and add regression coverage for both cases.
|
Addressed both issues. Qualified fork heads are now capability-gated to GitHub and Gitea, while unsupported providers reject fork pushes before pushing. Qualified heads validate by domain and owner without requiring matching repository names, so renamed forks are supported. Regression tests, race tests, build and lint all pass. |
Closes #152
Summary
Add an opt-in
--pushflag toforge pr create, allowing the command to push the specified head branch before creating the pull request.Changes
--pushtoforge pr creategit.PushBranchhelperUsage
forge pr create \ --title "My pull request" \ --head feature-branch \ --pushThe remote defaults to origin and respects the existing global --remote option.
Testing
All checks pass.