Breaking behavior change: pushing topic branch to wrong remote

[heaths]

Describe the bug

I've been testing gh for quite a while now, and even in v0.12.0 when I ran gh pr create -w the branch was pushed to my origin remote automatically. I was never asked (my clone uses origin for my fork and upstream for the main). Now in v1.0, I was asked:

Which should be the base repository (used for e.g. querying issues) for this directory?

It listed both endpoints, and since the message above reads, "e.g. for querying issues", I chose upstream.

It then printed and acted on accordingly,

Opening github.com/Azure/azure-sdk-for-net/compare/master...issue15108 in your browser.

That's not where my topic branch was even pushed to manually and has a tracking branch set up. I previously ran git push -u origin issue15108 which completed successfully.

Steps to reproduce the behavior

1. Make changes and commit to repo
2. Push topic branch to origin with tracking branch set up
3. Run: gh pr create -w

Expected vs actual behavior

• Expected: Browser is opened with my topic branch on my origin targeting master on upstream
• Actual: Browser is opened with my topic branch name from upstream targeting master, and topic branch does not exist in upstream.

Logs

Nothing more was printed than what I typed above.

[mislav]

@heaths Thank you for reporting!

After you've pushed to origin, is there an origin/issue15108 tracking branch? gh was supposed to find that branch and realize that you've pushed to origin, not upstream. Not sure why that didn't happen, but the info you provided us is useful 🙇

[heaths]

Yes, I set the tracking branch on push.

[mislav]

@heaths Thank you! I will investigate this next week. Sorry for the trouble!

Protip: you can get more verbose logging with DEBUG=1, which will show the underlying git comands getting executed. Please paste us whatever you find interesting that way 🙇

[heaths]

Thanks. I'll try to repro later. How can I undo the setting to set what I was prompted for? I figured that had something to do with it. A list verb on gh config would be nice (I'd be happy to contribute one if there's no reason not to add one).

[mislav]

@heaths The base repo setting can be reset with:

git config --unset remote.origin.gh-resolved

[vilmibm]

We have an issue for gh config list ( #859 ) but it's worth noting that here the relevant config is stored with git's config, something we do for per-repository settings.

I think in addition to anything like gh config list we ought to have a new help topic (like we did for env) that enumerates not just what gh supports internally but what config we rely on in git config.

[heaths]

Could this also be the same problem that is causing gh pr create to fail to detect the upstream and origin branches? I just pushed my commit to origin, and even if I run gh pr create -w to do it manually, gh opens https://github.com/Azure/azure-sdk-for-net/compare/master...keyvaultproxy-sample?expand=1 - all against upstream.

git config --get remote.origin.gh-resolved shows nothing (not set); however, I do see it for upstream in .git/config:

[remote "upstream"]
	url = https://github.com/Azure/azure-sdk-for-net.git
	fetch = +refs/heads/*:refs/remotes/upstream/*
	gh-resolved = base