I have to admit that I saw upstream/master, though "not again" and then did not read your question properly. You can still learn something from the things I have said below, but you actually put the finger on a bug.
I have fixed the bug by using remote/branch...pr instead of branch...pr. remote/branch is much more likely to be up-to-date because pulling the pr also updates remote tracking refs but not local branches.
It would be better if upstream were named origin. That's the convention and if you don't diverge from it then a lot of things will just work and you won't have to configure them explicitly. Setting forge.remote for example won't be necessary anymore.
I could say a few things about you the upstream and the push-remote and how they are not the same thing but both useful. But I have done that so many times I just link to my article about that instead -> The Two Remotes.
I am guessing that the reason why you don't name the upstream origin is that that name is already used for your fork. You can easily prevent that from happening in the future:
- Stop cloning your fork and then adding a remote for the upstream.
- Instead clone upstream and then add a remote for your fork. You can add your remote using the
forge-fork. If your fork does not exist yet, then it creates it. Then it adds the fork as a remote.
If you are not in the habit of keeping master up-to-date, then it is better to use origin/master as the upstream of your feature branches instead of master. That way d u shows the changes on your feature branch without having to first check out master, pull and then check out some-feature again.
You can change the upstream using b u. You probably also want to set magit-prefer-remote-upstream (which see).
