Repository navigation
When creating a PR from a fork using pr create, I should be able to have an inutitive path to successfully create one targeting the remote #172
Description
There are a few ways we could go about this:
1: It Just Works™
I think @mislav has more concrete thoughts on this direction! This could be really delightful and easy but my concern here is blocking behavior for anyone who doesn't want this behavior, or it being too quick and leaving people confused at what just happened
2: Flag + Survey
I think we could include a flag for this and a survey prompt like we do for title and body:
~/Projects/my-project$ gh pr create
Creating pull request for [branch] into [master]
? Repository
> desktop/desktop
ampinsk/desktop
? Title Title
? Body (nano) <Received>
? Submit?
> yes
edit
cancel
https://github.com/desktop/desktop/pulls/4
Plus add a flag (language WIP):
-r, --repo The repository you want your pull request opened in
@olgabot also left a great comment here outlining how she'd expect it to work: https://github.com/github/homebrew-gh/issues/6#issuecomment-566622632
Curious to hear thoughts!
Metadata
Metadata
Assignees
Labels
No labels
Activity
mislav commentedon Dec 20, 2019
In my experience, these are the most common cases which a person might find themselves in when creating a PR within the context of a local git repo:
They have write access to the main ("base", "parent") repository. In this case, we default to creating “same-repo” PRs, since their head branch is getting pushed to the same repository that the PR is created in. We currently cover this case well. ✅
There might be a valid reason for the user wanting to push their head branch to a fork rather than to the parent repo even if they have write access to the parent repo, but I'm not convinced that this case is very common and therefore I don't feel that we should prioritize this just yet.
They don't have write access to the main repo, but they do have a fork. For this case, I propose we 1) automatically push the head branch to their fork and 2) open the PR in the parent repo.
We should keep in mind that a person might have cloned their fork locally instead of cloning the parent repo + adding their fork as an additional git remote. I propose that the above feature works identically in either case, to reduce confusion.
There might be a valid reason for them wanting to open the PR in their fork instead of the parent repo, but I don't think this case is very common nor that we should prioritize this.
They don't have write access to the main repo and they don't have a fork; e.g. a first-time contributor. For this case, I propose we 1) automatically fork the base repo, 2) push the head branch to their fork, and 3) open the PR in the parent repo.
For me, the above scenarios cover most daily use-cases of opening PRs on GitHub:
This is what I intend to implement in this first iteration. In the future, we can offer people fine-grained controls over exactly which repo does their code get pushed to vs. their PR created in (the latter we could enable via
-R), but for now I'm inclined to cover the Just Works approach and see how well we can empower our users to get things done without having them pass extra command-line flags or spell out git remote names.vilmibm commentedon Dec 20, 2019
I'm comfortable with this approach! My only concern is for:
I've seen folks (including myself) opening PRs in forks just to keep track of work they don't intend to send upstream. In this case, is it accurate that
-R me/forkis sufficient for enabling that?cangencer commentedon Feb 11, 2020
@mislav I'd like to disagree with this. All of our developers have access to main repos, but we don't want to clutter the main repo with lots of single-use PR branches, as all commits have to go through a PR process. Is there a chance you'd fix this?
Remove redundant permissions block (cli#172)