git rebase upstream/master vs git pull --rebase upstream master

Is there a difference between git rebase upstream/master and git pull --rebase upstream master, and if so, what? The remote could be any remote, not necessarily upstream.

Solution 1:

The git pull --rebase will fetch (git fetch) first, updating upstream/master commits.

If you just rebase without first updating upstream/master, you won't get the same result.

I illustrate it in "master branch and 'origin/master' have diverged, how to 'undiverge' branches'?"

SnakE mentions in the comments that git pull --rebase isn't exactly git fetch && git rebase origin/master.
See "what does "git pull --rebase" do?"

(origin/master)
   |
A--B--C (master)
 \ 
  B'--D (actual origin/master after changing B and force pushing)

What git pull --rebase does, in this case, is:

git fetch origin
git rebase --onto origin/master B master

Here:

• origin/master is the new updated origin/master (B')
• B is the old origin/master (before a fetch updated it)
• master is the branch to replay on top of origin/master

This differs from git fetch + git rebase origin/master in that the pull --rebase command tries to find out which commits are really your local ones, and which had come from upstream in an earlier fetch.

To do this, it looks at the reflog of the remote tracking branch (origin/master, in this case). This reflog represents the tips of successive git fetch operations on origin, in "most recent first" order.

For each reflog entry, (origin/master@{1}, then ...{2}, and so on) it checks if that commit is an ancestor of the current branch head master. As soon as it finds one, it picks it as the starting point for the rebase (B in the example above).