Git fast forward merge is FORWARD in terms of TIME. The pointer goes from older to newer commits.
Example (by ffwd merge master pointer is moved from commit D to commit G):
Before fast-forward merge:
master
|
A<--B<--B<--D<--E<--F<--G
|
new_branch
After fast-forward merge:
master
|
A<--B<--B<--D<--E<--F<--G
|
new_branch
But, since the commit pointers point from newer to older, in terms of these pointers strictly, the branch pointer goes backwards... upstream the commit pointers. So in that sense, it can be labeled a fast-reverse merge. Upstream (the term from ProGit book, chapter on merging) refers to reverse flow, up-the-stream, so explaining upstream flow as a fast forward thing can confuse newcomers. So, it's:
Upstream in terms of commit pointers.
Forward in terms of commit time.
Does this reasoning make sense?
No, it don't move
master
to "G". It just start with "G" and ff to "D".master
is just a name/label thingy (calledref
). It is updated after merge, not "move" in steps.To understand this, you can just try a merge with conflict. When the merge is awaiting manual resolve, the branches are still points to their old commit. Just the checkout tree and index are in the indeterminate state.
update: May be you can think in this way:
git merge-base D G
, this is Gmaster
, overwrite the old one.