git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 6/7] Documentation: merge: add a section about fast-forward

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Jan 23, 2010, 09:45 UTC
Message-ID
<20100123094533.GG7571@progeny.tock>
In-Reply-To
<20100123092551.GA7571@progeny.tock>

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>
---
Sometimes people ask on IRC.
 Documentation/git-merge.txt |   31 ++++++++++++++++++-------------
 1 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 3663d58..0b86f2b 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -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.
-- 
1.6.6
Previous: Jonathan NiederNext: Jonathan Nieder
Message 8 of 11 in “clarify 'git merge' documentation”
  1. 0/7 clarify 'git merge' documentationJonathan Nieder, Jan 23, 2010
  2. 1/7 Documentation: merge: move configuration section to endJonathan Nieder, Jan 23, 2010
  3. 2/7 Documentation: suggest `reset --merge` in How Merge Works sectionJonathan Nieder, Jan 23, 2010
  4. 3/7 Documentation: merge: move merge strategy list to endJonathan Nieder, Jan 23, 2010
  5. 4/7 Documentation: merge: add an overviewJonathan Nieder, Jan 23, 2010
  6. Raja R HarinathFeb 12, 2010
  7. 5/7 Documentation: emphasize when git merge terminates earlyJonathan Nieder, Jan 23, 2010
  8. 6/7 Documentation: merge: add a section about fast-forwardJonathan Nieder, Jan 23, 2010
  9. 7/7 Documentation: simplify How Merge WorksJonathan Nieder, Jan 23, 2010
  10. Thomas RastJan 24, 2010
  11. Junio C HamanoJan 24, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.