After moving repo to a new org, pr create adds a new remote named fork every time

[nicolas-christe]

Describe the bug

Each time I create a PR using gh-cli, a new git remote named 'fork' is added to my config.

Steps to reproduce the behavior

$ gh pr create

? Where should we push the 'xxx' branch?

Creating pull request for xxx in user/repo

? Title
? Body
? What's next? Submit
Added user/repo as remote "fork"

Expected vs actual behavior

I creating a PR on my repo, my git config already has the remote named origin, gh-cli should not create a new remote named fork joining to the same url than origin

[williammartin]

Interesting. Before we dig too deep can you share the contents of .git/config and git remote -v?

I believe we only intend to use fork if we can't find a remote called origin. but maybe something further up the chain loading the remotes is failing and we're not surfacing that error.

[nicolas-christe]

Looking at the code you pointed out I found the issue: my repo has been transferred to a new organisation, and .git/config still contains the remote pointing to the old organisation. Everything is working fine thanks to GitHub automatically forwarding the old url to the new organisation, excepted this issue with gh-cli.
Thanks

[williammartin]

Ah, that makes a lot of sense and was reproducible for me:

➜  workspace gh repo clone https://github.com/williammartin/gomodtesting
Cloning into 'gomodtesting'...
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 1), reused 6 (delta 1), pack-reused 0
Receiving objects: 100% (6/6), done.
Resolving deltas: 100% (1/1), done.

➜  workspace cd gomodtesting

➜  gomodtesting git:(main) git checkout -b 9002-triage
Switched to a new branch '9002-triage'
➜  gomodtesting git:(9002-triage) touch 9002-triage && git add . && git commit -m "9002-triage"
[9002-triage adefb6f] 9002-triage
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 9002-triage

<-------- At this point I moved the repo to williammartin-test-org

➜  gomodtesting git:(9002-triage) gh pr create
? Where should we push the '9002-triage' branch? williammartin-test-org/gomodtesting

Creating pull request for 9002-triage into main in williammartin-test-org/gomodtesting

? Title 9002-triage
? Body <Received>
? What's next? Submit
Added williammartin-test-org/gomodtesting as remote "fork"
remote:
remote:
To https://github.com/williammartin-test-org/gomodtesting.git
 * [new branch]      HEAD -> 9002-triage
branch '9002-triage' set up to track 'fork/9002-triage'.
https://github.com/williammartin-test-org/gomodtesting/pull/1

➜  gomodtesting git:(9002-triage) git remote -v
fork    https://github.com/williammartin-test-org/gomodtesting.git (fetch)
fork    https://github.com/williammartin-test-org/gomodtesting.git (push)
origin  https://github.com/williammartin/gomodtesting.git (fetch)
origin  https://github.com/williammartin/gomodtesting.git (push)

I've updated the title to reflect this for better discoverability. I'm not totally sure what we should do about this use case. Something similar was reported in #345. It seems like we could do something here aside from asking the user to update their remotes.

When we start the process of gathering data for pr create we query for the RepositoryNetwork:

fragment repo on Repository {
    id
    name
    owner { login }
    viewerPermission
    defaultBranchRef {
      name
    }
    isPrivate
  }
  query RepositoryNetwork {
    viewer { login }

    repo_000: repository(owner: "williammartin", name: "gomodtesting") {
      ...repo
      parent {
        ...repo
      }
    }

And the API knows that this repository williammartin/gomodtesting has moved, and returns the right information:

{
  "data": {
    "viewer": {
      "login": "williammartin"
    },
    "repo_000": {
      "id": "R_kgDOLpRgvg",
      "name": "gomodtesting",
      "owner": {
        "login": "williammartin-test-org"
      },
      "viewerPermission": "ADMIN",
      "defaultBranchRef": {
        "name": "main"
      },
      "isPrivate": false,
      "parent": null
    }
  }
}

Which we use to present the dialog, and use as the information for the remote to be added. I wonder we could understand that repo_000 in the query and repo_000 in the response were different and infer that the repo must have moved. With that inference perhaps we could use the original remote that we resolved rather than trying to create a new fork.

I haven't dug into the details to confirm how hard this would be since the code looks pretty thorny, and this can also be addressed client side by updating the remote so it seems low priority. Tagging it help wanted if anyone wants to do the work on this. Cheers!