Skip to content

Commit

Permalink
Documentation: merge: add a section about fast-forward
Browse files Browse the repository at this point in the history
Novices sometimes find the behavior of 'git merge' in the
fast-forward case surprising.  Describe it thoroughly.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
  • Loading branch information
Jonathan Nieder authored and Thomas Rast committed Jan 24, 2010
1 parent 30f2bad commit 2928031
Showing 1 changed file with 18 additions and 13 deletions.
31 changes: 18 additions & 13 deletions Documentation/git-merge.txt
Original file line number Diff line number Diff line change
Expand Up @@ -86,25 +86,30 @@ would result from the merge already.)
If all named commits are already ancestors of `HEAD`, 'git merge'
will exit early with the message "Already up-to-date."

FAST-FORWARD MERGE
------------------

Often the current branch head is an ancestor of the named commit.
This is the most common case especially when invoked from 'git
pull': you are tracking an upstream repository, you have committed
no local changes, and now you want to update to a newer upstream
revision. In this case, a new commit is not needed to store the
combined history; instead, the `HEAD` (along with the index) is
updated to point at the named commit, without creating an extra
merge commit.

This behavior can be suppressed with the `--no-ff` option.

HOW MERGE WORKS
---------------

A merge is always between the current `HEAD` and one or more
commits (usually a branch head or tag).

Two kinds of merge can happen:

* `HEAD` is already contained in the merged commit. This is the
most common case especially when invoked from 'git pull':
you are tracking an upstream repository, have committed no local
changes and now you want to update to a newer upstream revision.
Your `HEAD` (and the index) is updated to point at the merged
commit, without creating an extra merge commit. This is
called "Fast-forward".

* Both the merged commit and `HEAD` are independent and must be
tied together by a merge commit that has both of them as its parents.
The rest of this section describes this "True merge" case.
Except in a fast-forward merge (see above), the branches to be
merged must be tied together by a merge commit that has both of them
as its parents.
The rest of this section describes this "True merge" case.

The chosen merge strategy merges the two commits into a single
new source tree.
Expand Down

0 comments on commit 2928031

Please sign in to comment.