Use "git merge" instead of "git pull ."
"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.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Ackermann committed
Aug 27, 2013 at 19:58 UTC
a7bdee1122297442ac8eaaecf20db7363d48a14e
1 file changed
+4
-4
Documentation/user-manual.txt
+4
-4
@@ -1793,7 +1793,7 @@ $ git pull . branch
1793
$ git merge branch
1794
-------------------------------------------------
1795
1796
-are roughly equivalent. The former is actually very commonly used.
1796
+are roughly equivalent.
1797
1798
[[submitting-patches]]
1799
Submitting patches to a project
@@ -2255,11 +2255,11 @@ commit to this branch.
2255
$ ... patch ... test ... commit [ ... patch ... test ... commit ]*
2256
-------------------------------------------------
2257
2258
-When you are happy with the state of this change, you can pull it into the
2258
+When you are happy with the state of this change, you can merge it into the
2259
"test" branch in preparation to make it public:
2260
2261
-------------------------------------------------
2262
-$ git checkout test && git pull . speed-up-spinlocks
2262
+$ git checkout test && git merge speed-up-spinlocks
2263
-------------------------------------------------
2264
2265
It is unlikely that you would have any conflicts here ... but you might if you
@@ -2271,7 +2271,7 @@ see the value of keeping each patch (or patch series) in its own branch. It
2271
means that the patches can be moved into the `release` tree in any order.
2272
2273
-------------------------------------------------
2274
-$ git checkout release && git pull . speed-up-spinlocks
2274
+$ git checkout release && git merge speed-up-spinlocks
2275
-------------------------------------------------
2276
2277
After a while, you will have a number of branches, and despite the