"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>
maint
Thomas Ackermann12 years agocommitted byJunio C Hamano
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.
@@ -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
@@ -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.