git rebase upstream/master vs git pull --rebase upstream master
git, git-pull, git-rebase
Solution
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).
Problem
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.