"git pull ." works, but "git merge" is the recommended
way for new users to do things. (The old description 
also should have read "The former is actually *not* very
commonly used".)

Signed-off-by: Thomas Ackermann <th.ac...@arcor.de>
 Documentation/user-manual.txt | 15 ++-------------
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index b450980..8a1a441 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1784,17 +1784,6 @@ repository that you pulled from.
 <<fast-forwards,fast-forward>>; instead, your branch will just be
 updated to point to the latest commit from the upstream branch.)
-The `git pull` command can also be given `.` as the "remote" repository,
-in which case it just merges in a branch from the current repository; so
-the commands
-$ git pull . branch
-$ git merge branch
-are roughly equivalent.  The former is actually very commonly used.
 Submitting patches to a project
@@ -2259,7 +2248,7 @@ When you are happy with the state of this change, you can 
pull it into the
 "test" branch in preparation to make it public:
-$ git checkout test && git pull . speed-up-spinlocks
+$ git checkout test && git merge speed-up-spinlocks
 It is unlikely that you would have any conflicts here ... but you might if you
@@ -2271,7 +2260,7 @@ see the value of keeping each patch (or patch series) in 
its own branch.  It
 means that the patches can be moved into the `release` tree in any order.
-$ git checkout release && git pull . speed-up-spinlocks
+$ git checkout release && git merge speed-up-spinlocks
 After a while, you will have a number of branches, and despite the

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to