Re: [PATCH] user-manual.txt: fix a few mistakes

"J. Bruce Fields" [off-list ref] writes:

On Tue, Nov 13, 2007 at 09:19:39PM +0300, Sergei Organov wrote:

quoted

Signed-off-by: Sergei Organov <redacted>
---
 Documentation/user-manual.txt |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d99adc6..a169ef0 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt

@@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this
 If you run "git branch" at this point, you'll see that git has
 temporarily moved you to a new branch named "bisect".  This branch
 points to a commit (with commit id 65934...) that is reachable from
-v2.6.19 but not from v2.6.18.  Compile and test it, and see whether
+"master" but not from v2.6.18.  Compile and test it, and see whether
 it crashes.  Assume it does crash.  Then:
 
 -------------------------------------------------

@@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
 fundamentally different ways to fix the problem:
 
 	1. You can create a new commit that undoes whatever was done
-	by the previous commit.  This is the correct thing if your
+	by the old commit.  This is the correct thing if your
 	mistake has already been made public.
 
 	2. You can go back and modify the old commit.  You should

@@ -1567,8 +1567,8 @@ old history using, for example,
 $ git log master@{1}
 -------------------------------------------------
 
-This lists the commits reachable from the previous version of the head.
-This syntax can be used to with any git command that accepts a commit,

I actually prefer "head" here.  On something like:

		 A--B--C
		/
	o--o--o
		\
		 o--o--o


The term "branch" could be used to refer to the whole line of
development consisting of A, B, and C.  The term "head", on the other
hand, refers to either C or a ref that points to it.  We also use the
terms "branch head" or just "branch" for that case, but I think "head"
is more precise.

Then I'd suggest to be precise here, e.g.:

"This lists the commits reachable from the previous version of the
"master" branch head."

The real reason for me to replacing "head" with "branch" in the first
place was that a few lines below there is example for HEAD, and I wanted
to make it more obvious that those is entirely different.

-- 
Sergei.

On Thu, Nov 15, 2007 at 01:36:40PM +0300, Sergei Organov wrote:

"J. Bruce Fields" [off-list ref] writes:

quoted

On Tue, Nov 13, 2007 at 09:19:39PM +0300, Sergei Organov wrote:

quoted

Signed-off-by: Sergei Organov <redacted>
---
 Documentation/user-manual.txt |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d99adc6..a169ef0 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt

@@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this
 If you run "git branch" at this point, you'll see that git has
 temporarily moved you to a new branch named "bisect".  This branch
 points to a commit (with commit id 65934...) that is reachable from
-v2.6.19 but not from v2.6.18.  Compile and test it, and see whether
+"master" but not from v2.6.18.  Compile and test it, and see whether
 it crashes.  Assume it does crash.  Then:
 
 -------------------------------------------------

@@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
 fundamentally different ways to fix the problem:
 
 	1. You can create a new commit that undoes whatever was done
-	by the previous commit.  This is the correct thing if your
+	by the old commit.  This is the correct thing if your
 	mistake has already been made public.
 
 	2. You can go back and modify the old commit.  You should

@@ -1567,8 +1567,8 @@ old history using, for example,
 $ git log master@{1}
 -------------------------------------------------
 
-This lists the commits reachable from the previous version of the head.
-This syntax can be used to with any git command that accepts a commit,

I actually prefer "head" here.  On something like:

		 A--B--C
		/
	o--o--o
		\
		 o--o--o


The term "branch" could be used to refer to the whole line of
development consisting of A, B, and C.  The term "head", on the other
hand, refers to either C or a ref that points to it.  We also use the
terms "branch head" or just "branch" for that case, but I think "head"
is more precise.

Then I'd suggest to be precise here, e.g.:

"This lists the commits reachable from the previous version of the
"master" branch head."

That sounds sensible to me, sure.

The real reason for me to replacing "head" with "branch" in the first
place was that a few lines below there is example for HEAD, and I wanted
to make it more obvious that those is entirely different.

OK, sure.  Thanks for the thoughtful editing!

--b.