CODEWITHSUNDEEP
gitmergegit-mergerebasegit-rebase
bit
bit

Reputation: 509

How can rebasing simulate a fast-forward in a non-fast-forward merge?

The bitbucket documentation says:

A non-fast-forward merge is a merge where the master branch had intervening changes between the branch point and the merge back to the master. In this case, a user can simulate a fast-forward by rebasing rather than merging. Rebasing works by abandoning some commits and creating new ones.

Let's say we have a non-fast-forward merge:

- o - o - o - H - A - B - C   <-- master (HEAD)
               \
                P - Q - R   <-- origin/master

According to the above quote from the bitbucket documentation rebasing can simulate a fast-forward. However by executing the commands:

git checkout master
git pull --rebase

git rebase which is called by git pull --rebase, just takes the commits in the branch master that was checked out and adds them to the new base which is origin/master, resulting in:

- o - o - o - H - P - Q - R - A' - B' - C'   <-- master (HEAD)
                          |
                          <-- origin/master

A fast-forward (when possible) fast-forwards (i.e. moves forward in time) the master branch's pointer to point to the last commit of the branch that is to be merged. However as shown in the 2nd commit graph rebasing causes HEAD to be at C' which is not the same as a fast-forward because as shown in the 2nd commit graph rebasing creates 3 new commits A', B' and C' instead of fast-forwarding the pointer of the master branch to match the commits that were merged (a fast-forward would cause HEAD to be at R).

So how can git rebase simulate a fast-forward in a non-fast-forward merge or is that statement from the bitbucket documentation incorrect?

Upvotes: 2

Views: 776

Answers (1)

VonC
VonC

Reputation: 1329592

What will be "fast-forward-like" (after a rebase) is the "git push": origin/master will simply be updated to master commit locally and on the remote side.
(Assuming no other commits were pushed to origin in the meantime by someone else)

- o - o - o - H - P - Q - R - A' - B' - C'   <-- master (HEAD)
                          |
                          <-- origin/master

git push

- o - o - o - H - P - Q - R - A' - B' - C'   <-- master (HEAD), origin/master

SO the end result of a rebase + push would be the same as a fast-forward merge where master would have been behind origin/master

- o - o - o - H - P - Q - R - A' - B' - C'   <-- origin/master
                          |
                          <-- master (HEAD)

git pull: fetch + fast-forward merge 

- o - o - o - H - P - Q - R - A' - B' - C'   <-- master (HEAD), origin/master

Upvotes: 1

Related Questions