"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 <redacted>
---
Documentation/user-manual.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 3f44ca0..6241a43 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1793,7 +1793,7 @@ $ git pull . branch
$ git merge branch
-------------------------------------------------
-are roughly equivalent. The former is actually very commonly used.
+are roughly equivalent.
[[submitting-patches]]
Submitting patches to a project
@@ -2255,11 +2255,11 @@ commit to this branch.
$ ... patch ... test ... commit [ ... patch ... test ... commit ]*
-------------------------------------------------
-When you are happy with the state of this change, you can pull it into the
+When you are happy with the state of this change, you can merge 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 +2271,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
--
1.8.3.msysgit.0
---
Thomas