Junio C Hamano <gits...@pobox.com> writes: > Sergey Organov <sorga...@gmail.com> writes: > >> So I believe this change is inline with the rest of the patch. The >> reference to git-pull (if it remains) should be a side-note, not part of >> explanation of operation. > > Not really. The thing is, "This is the most common" needs to be > close to "Often...". "git merge" directly invoked by the end user > is much less likely to encounter a fast forward situation; getting > invoked indirectly by "git pull" makes it common.
Ah, I now see. I tried to keep the text intact as much as possible, and only split it into description and a note. Well, how about this then: diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index b758d55..479400f 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -135,15 +135,17 @@ 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 +When current branch head is an ancestor of the named commit, +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 is very common case when 'git merge' is 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. + This behavior can be suppressed with the `--no-ff` option. TRUE MERGE -- Sergey
