Re: [PATCH 04/11] Use "git merge" instead of "git pull ."

2013-08-27 Thread Junio C Hamano
Jonathan Nieder  writes:

> On Tue, Aug 27, 2013 at 12:06:33PM -0700, Junio C Hamano wrote:
>> Thomas Ackermann  writes:
>> 
>> > "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".)
>> 
>> It does not matter that you are unaware other people use it often.
>> I'd suggest dropping the first hunk altogether.
>
> Eh, the claim "The former is actually very commonly used." is
> confusing on its own (even though it used to be true) and elaborating
> wouldn't help much with education, so the first hunk makes sense to
> me.  But maybe it should have been done in a separate patch. ;-)

Yeah, it may make sense to replace it with something like "... and
if you think about the fact that your local repository is not at all
special, it makes sense that you can pull from it just like you pull
from other places", without mentioning how common it is.  I do agree
that it is a separate topic.
--
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


Re: [PATCH 04/11] Use "git merge" instead of "git pull ."

2013-08-27 Thread Jonathan Nieder
On Tue, Aug 27, 2013 at 12:06:33PM -0700, Junio C Hamano wrote:
> Thomas Ackermann  writes:
> 
> > "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".)
> 
> It does not matter that you are unaware other people use it often.
> I'd suggest dropping the first hunk altogether.

Eh, the claim "The former is actually very commonly used." is
confusing on its own (even though it used to be true) and elaborating
wouldn't help much with education, so the first hunk makes sense to
me.  But maybe it should have been done in a separate patch. ;-)

Thanks,
Jonathan
--
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


Re: [PATCH 04/11] Use "git merge" instead of "git pull ."

2013-08-27 Thread Junio C Hamano
Thomas Ackermann  writes:

> "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".)

It does not matter that you are unaware other people use it often.
I'd suggest dropping the first hunk altogether.
--
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


[PATCH 04/11] Use "git merge" instead of "git pull ."

2013-08-27 Thread Thomas Ackermann

"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 
---
 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
--
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