Support multiple remotes for PRs #936
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 5 commits
October 4, 2025 10:12
- Taught `GitService::get_github_repo_info` to accept an optional preferred remote and to fall back gracefully when it’s missing, so repo metadata lines up with branch configuration (`crates/services/src/services/git.rs:1677`). - Updated `GitService::push_to_github` to honor the branch’s upstream remote, including upstream tracking updates, which lets pushes land on the correct remote before PR creation (`crates/services/src/services/git.rs:1747`). - During PR creation and PR attachment we now look up the branch’s configured remote and pass it through when building GitHub repo info, keeping both flows aligned with the selected upstream (`crates/server/src/routes/task_attempts.rs:739`, `crates/server/src/routes/task_attempts.rs:1347`). - Added coverage proving the preferred-remote path works alongside the existing default-remote test (`crates/services/tests/git_workflow.rs:332`). **Tests** - `cargo test -p services get_github_repo_info` - `cargo check -p server` **Next Steps** - Manually trigger PR creation against a non-default remote to confirm the end-to-end behavior matches expectations.
…or attaching a PR, so the GitHub repo is resolved against that remote (typically `origin`) instead of whichever remote the feature branch happens to push to (`crates/server/src/routes/task_attempts.rs:739`, `crates/server/src/routes/task_attempts.rs:1356`). - The base-remote discovery is kept alongside the existing head-remote check and falls back to it only if the base branch has no upstream, preserving support for unconventional setups (`crates/server/src/routes/task_attempts.rs:745`). - The Git service helper already understands a preferred remote, so no changes were needed there beyond the earlier update. Tests: - `cargo check -p server` Next: try opening a PR from a branch that tracks `origin/main` to confirm the dialog now targets the upstream remote.
- Added first-class remote metadata in the git service, exposing `GitRemote` and a `get_all_remotes` helper so we can enumerate configured remotes (`crates/services/src/services/git.rs:68`, `crates/services/src/services/git.rs:1716`). A new test covers the behaviour (`crates/services/tests/git_workflow.rs:360`). - Exposed the remotes list through the projects API and router so the frontend can request it (`crates/server/src/routes/projects.rs:47`, `crates/server/src/routes/projects.rs:488`). - Let PR creation requests carry an explicit remote hint and respect it on the server, while still falling back to branch defaults when none is provided (`crates/server/src/routes/task_attempts.rs:88`, `crates/server/src/routes/task_attempts.rs:772`). - Introduced a remote selector in the Create PR dialog, defaulting to `origin` when available but letting users override per PR; the selection is passed along in the request and re-used on reopen (`frontend/src/components/dialogs/tasks/CreatePRDialog.tsx:47`, `frontend/src/components/dialogs/tasks/CreatePRDialog.tsx:140`). - Surfaced a lightweight `projectsApi.getRemotes` helper and regenerated shared types so TypeScript stays in sync (`frontend/src/lib/api.ts:249`, `shared/types.ts:86`). **Tests** - `cargo test -p services get_github_repo_info` - `cargo test -p services get_all_remotes_returns_all_configured_remotes` - `cargo check -p server` - `npm run generate-types` - `npm run check` **Next Steps** 1. Try the new dialog on a branch that tracks `origin/main` to confirm the selector defaults to the desired remote and that choosing another remote routes the PR correctly.
…configured upstream remote (usually your fork) instead of whatever remote you chose as the PR target. That change lives in `crates/server/src/routes/task_attempts.rs:677` and `crates/services/src/services/git.rs:1769`. It both fixes the standalone “Push branch” action and ensures PR creation pushes to the fork before we talk to GitHub. - When we build the PR payload we now capture the fork’s repo info and pass it to GitHub, so the head ref is written as `owner:branch` whenever the head repo differs from the base (`crates/server/src/routes/task_attempts.rs:798`, `crates/services/src/services/github_service.rs:121`). GitHub now checks the branch in the correct repository and accepts cross‑account PRs. Tests: `cargo check -p server` Next step: reopen the Create PR dialog, leave the remote selector pointing at `origin` (the base), and try again—the backend will push `greg/7011-why-do-we-not-su` to your fork first, then open the PR against origin using the forked branch.
…so you can decide which remote your branch is pushed to. The dialog now submits both `remote_name` (PR target) and `head_remote_name` (branch source), defaulting to sensible heuristics like `fork` when it’s present (`frontend/src/components/dialogs/tasks/CreatePRDialog.tsx:11`, `frontend/src/components/dialogs/tasks/CreatePRDialog.tsx:170`). - Extended the backend request type to carry that new field, regenerated the shared types, and taught the PR route to push the branch to the chosen source remote before calling GitHub. It now looks up the repo info for that remote and formats the head ref correctly for cross-account PRs (`crates/server/src/routes/task_attempts.rs:723`). - Updated the GitHub service to accept the optional head-repo metadata and to build the `owner:branch` ref when the branch lives on a different repo than the base (`crates/services/src/services/github_service.rs:121`). Tests: - `npm run check` - `cargo check -p server` Next step: reopen the Create PR dialog, pick `origin` for the base repo and `fork` (or whichever fork remote) for the source remote, and try again—the backend now pushes to your fork first and GitHub should accept the head branch.
|
Perhaps stick it under an "Advanced >" disclosure? |
gburch
force-pushed
the
vk/25a7-support-multiple
branch
from
fbabe29 to
10c9095
Compare
gburch
force-pushed
the
vk/25a7-support-multiple
branch
from
10c9095 to
fd12741
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Let users choose the remote:
Add a remote selector to the Create PR dialog, so users can explicitly choose which remote to create the PR against.
Default the branch's configured remote
The code already has logic to get the remote from a branch's configuration (get_remote_from_branch_ref), but get_github_repo_info() doesn't use it - it just uses the default remote.