Fast-forward merges have properties that are tightly tied together (basically they are equivalent)...
- A fast-forward merge is exactly the sort of merge that doesn't create a merge commit (assuming that you aren't doing destructive operations on commit history).
- A fast-forward merge is exactly the sort of merge that just updates the branch pointer. (Remember that `git pull` first does a `fetch` to get the remote commits before the merge happens, so a merge "just updating the branch pointer" can involve commits that didn't exist locally until the fetch.)
- A merge is fast-forwardable exactly when the source commit history is a superset of the destination branch commit history.
- A merge is fast-forwardable exactly when the destination commit is an ancestor of the source commit.
A note on terminology. I have looked for the most official term for merges that are not fast-forward merges; these are the classical merges that create a merge commit. The closest I have found is "true merge" as a git-merge reference section header. Some people use the term "3-way merge" for all merges that create a merge commit, but 3-way merges are an algorithm for producing merge output where you also look at the most recent common ancestor of the two things you are merging, thus the name having "3" in it. True merges do not have to use the 3-way merge algorithm (see merge strategies). Thus, I will be using "true merge" or "non-fast-forward merge" to refer to merges that create a merge commit.
