Skip to content

PR creation has strange behaviour when remote changes #1032

Closed
#1706
Closed
PR creation has strange behaviour when remote changes#1032
#1706
Labels
bugSomething isn't workingmore-info-neededMore info needed from user/contributor

Description

@chrisfosterelli
chrisfosterelli
opened on May 28, 2020

Describe the bug

Using gh pr create after deleting and recreating my origin remote appears to lead to unclear error messages and a new remote for one of the repository's forks being added to my git config.

Steps to reproduce the behavior

I haven't tried to recreate this, just extrapolating from my case info below

  1. Create a feature branch and add some work
  2. Rename the repository on github
  3. Update your remote by removing it and readding it
  4. Attempt to gh pr create from the feature branch

Expected vs actual behavior

I would expect that I can create a pull request, in an ideal world. If something is strange with git, which I presume to be the case causing this, I would expect a better error message and not creating a new remote for a fork.

Instead I get an obscure error message and a new remote :)

Logs

I have been using the new gh pr create to create pull requests. Normally I push the branch up before I do this (though I'm not sure if that's actually required, I guess just my usual flow). When pushing my branch, I noticed github gave a notice: "This repository moved. Please use the new location:".

Github is right that I renamed that repository! I forgot. I thought it'd be good to fix that, so I git remote rm origin and then git remote add origin <correct SSH URL>.

I then go to follow up with a pull request using gh pr create, and get the following behavior:

➜ git:(fix-ispaid) gh pr create

Creating pull request for fix-ispaid into dev in chrisfosterelli/<repo name>

! warning: could not compute title or body defaults: fatal: ambiguous argument 'origin/dev...fix-ispaid': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
git: exit status 128
? Title Predefine isPaid so that user creation doesnt fail
? Body <Received>
? What's next? Submit
Username for 'https://github.com': ^C

The error is unusual, but appears that creation can go ahead as expected. But then I get an HTTP prompt, and suspect something is wrong because I only use SSH remotes. I check the remote that I added, and notice that gh pr create added a new remote for some reason, called fork, which is a fork a colleague made of my repo. It's an HTTP remote.

Very strange behaviour.

I'm able to fix it by git checkout dev && git pull origin dev. Then the gh pr create on my feature branch works normally. Not a big deal, but thought it was worth noting 😄

I imagine this has something to do with deleting the origin remote causing git to no longer have the remote context about origin/dev until I later git checkout dev && git pull origin dev. In either case this has worked with normal git flow doing PRs from the web interface, so I suspect the handling here could be a bit better.

Thanks for reading!

Activity

  1. chrisfosterelli
    added
    bugSomething isn't working
    on May 28, 2020

  2. chrisfosterelli commented on May 28, 2020

    @chrisfosterelli
    chrisfosterelli
    on May 28, 2020
    Author

    Small update: it turns out that, even after git checkout dev && git pull origin dev, the gh client no longer displays the error but still creates a brand new remote called fork. I had to also run git push origin fix-ispaid && git pull origin fix-ispaid to get it to stop creating the fork remote and successfully create the PR.

  3. mislav commented on May 28, 2020

    @mislav
    mislav
    on May 28, 2020
    Contributor

    Thank you for the detailed report! I'm sorry gh is giving you troubles.

    I check the remote that I added, and notice that gh pr create added a new remote for some reason, called fork, which is a fork a colleague made of my repo. It's an HTTP remote.

    Do you happen to have write access to your colleague's fork? This might have triggered the logic in which gh prefers to push branches to forks where you have write access instead of to the parent repo. #800

    But then I get an HTTP prompt, and suspect something is wrong because I only use SSH remotes.

    You may want to set gh config set git_protocol ssh to have gh always default to generating SSH-style git URLs. However, I don't think this alone will fix your problem with fork.

    I think that for now, you should keep using the workaround where you first push the branch git push origin HEAD and then gh pr create.

  4. mislav
    added
    more-info-neededMore info needed from user/contributor
    on May 28, 2020

  5. chrisfosterelli commented on May 28, 2020

    @chrisfosterelli
    chrisfosterelli
    on May 28, 2020
    Author

    I'm sorry gh is giving you troubles.

    Overall it's working great and this was just a small blip 😄

    Do you happen to have write access to your colleague's fork?

    It looks like I do, though I don't think it was explicitly given to me, rather I believe I have it implicitly because my repository is private. Looks like that is by design:

    Private forks inherit the permissions structure of the upstream or parent repository. For example, if the upstream repository is private and gives read/write access to a team, then the same team will have read/write access to any forks of the private upstream repository. This helps owners of private repositories maintain control over their code.

    If it helps, this is the repo structure here:

    chrisfosterelli/project-api (private main repo with new name)
    \-> colleague/project-lambda (colleague's fork, who hasn't updated the name)

    You may want to set gh config set git_protocol ssh to have gh always default to generating SSH-style git URLs.

    Thanks for the tip!

    I think you're right it seems tightly related to #800, though I don't know if it's precisely a duplicate. That issue seems to be when there is a primary org repository and no fork under the author's namespace, as they've chosen not to fork. In my case, the main repo is the one directly under my namespace, but it has tried pushing to my colleagues fork.

    I think the git error message that comes up during the attempt to create a PR prior to re-pulling dev is also separate.

  6. chrisfosterelli commented on May 28, 2020

    @chrisfosterelli
    chrisfosterelli
    on May 28, 2020
    Author

    Just rereading and saw your note here in #800 (comment):

    you can always choose a push target by first pushing with git

    If a manual push to a specific remote ever isn't respected as PR head, please open a separate issue. 🙇

    That's an interesting point and I think what I've been doing, and where the issue came in was that I saw the notice from Github during the push, and then changed my remote but didn't repush prior to gh pr create (and FWIW I don't suspect most people would think to as I'd figure it has to do with the remote data rather than local git data)

  7. mislav
    closed this as completedin #1706on Sep 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingmore-info-neededMore info needed from user/contributor

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions