Repository navigation
After moving repo to a new org, pr create adds a new remote named fork every time #9002
Description
Activity
Interesting. Before we dig too deep can you share the contents of
.git/configandgit remote -v?I believe we only intend to use
forkif we can't find a remote calledorigin. but maybe something further up the chain loading the remotes is failing and we're not surfacing that error.Looking at the code you pointed out I found the issue: my repo has been transferred to a new organisation, and
.git/configstill 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- changed the title
[-]gh-cli add a new git remote named 'fork' each time a PR is created[/-][+]After moving repo to a new org, `pr create` adds a new remote named `fork` every time[/+]on Apr 29, 2024 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 createwe query for theRepositoryNetwork: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/gomodtestinghas 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 if we could understand that
repo_000in the query andrepo_000in 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 wantedif anyone wants to do the work on this. Cheers!@williammartin I'd like to work on this..but my question is here "Should we ideally create a new remote/update existing remote inside the current working directory's .git/config?" or just create the PR with the new org's login and be done with it? In that latter case future operations would still be taking the old org's data unless we're specifically hitting the GH API.
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 namedforkjoining to the same url thanorigin