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

Activity

1. ampinsk

   added

   beta

   on Dec 17, 2019
2. mislav

   self-assigned this

   on Dec 19, 2019
3. mislav commented on Dec 20, 2019

   

   mislav

   on Dec 20, 2019

   Last edited by mislav

   Contributor

   More actions

   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:

   1. 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.

   2. 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.

   3. 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:

   • an organization member submitting their work for peer review;
   • an open source maintainer making updates to their own projects;
   • an open source contributor (both new and experienced) submitting pull requests.

   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.
4. vilmibm commented on Dec 20, 2019

   

   vilmibm

   on Dec 20, 2019

   Contributor

   More actions

   I'm comfortable with this approach! My only concern is for:

   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.

   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/fork is sufficient for enabling that?

   👍React with 👍1Reacted by Mislav Marohnić
5. mislav

   closed this as completedin #238on Jan 23, 2020
6. cangencer commented on Feb 11, 2020

   

   cangencer

   on Feb 11, 2020

   Last edited by cangencer

   More actions

   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.

   @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?
7. Stonre

   added a commit that references this issue on Jul 21, 2025

   Remove redundant permissions block (cli#172)

   a805919