When my cursor is at a pull request in status buffer, and I press "d d", then I get the diff of master...refs/pullreqs/XXX. This works as intended, if my master branch is up-to-date. However, sometimes my master branch doesn't have upstream changes merged, so this diff generates a bad output.

Is it possible to have "d d" make the diff of upstream/master...refs/pullreqs/XXX?

I know that I can press "d r" (diff-range), then "M-n" (copy the dwim-default to mini-buffer), and then prepend "upstream/". But still, having "upstream/master" as the default would be more convenient when reviewing PRs.

Note, in my .git/config, I have forge/remote set as:

        remote = upstream

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:

  1. Stop cloning your fork and then adding a remote for the upstream.
  2. 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).

| improve this answer | |
  • Thanks for your answer! Maybe I use names the other way around as they supposed to be. But still, I fail to see why renaming would solve my problem. If I don't have upstream's master (no matter whether it's called upstream/master or origin/master) merged in my local master branch, then my master is still out-of-date. So a diff between master...PR would still be invalid, isn't it? We should do a diff origin/master...PR, don't we? (I'm new to git and magit, so it's possible that I misunderstand something) – geza Jun 12 at 20:40
  • Note, I'm talking about PRs in the status buffer, which are not my feature branches. I'd like to review PRs without too much hassle. I just fetch all topics, then I'd like to simply use "d d" on a PR (without affecting my master branch). And I'm not sure whether I don't follow the conventions. I basically do exactly the same as this blog post describes: blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow (the point is the bullet-point list in the beginning, and the naming convention: the fork is called origin, and the original repo called upstream) – geza Jun 12 at 23:19
  • This should be fixed now. It required changes to forge and magit so both have to be updated. It can take a few hours for the updates to become available on Melpa. – tarsius Jun 14 at 11:00
  • Thank you, I can confirm that, it uses upstream/master...PR now. It's very convenient! Magit is awesome. – geza Jun 14 at 20:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.