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.
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
(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 successivegit fetch
operations onorigin
, 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 headmaster
. As soon as it finds one, it picks it as the starting point for the rebase (B
in the example above).