fast-export: fix comparison in tests

diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
index fcd64e9b9b6d53b46d31e0c797016e9881651604..4627ee47f2ce86761344e0a57aed2cada94b6b9c 100644 (file)
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -1,4 +1,4 @@
-From:  Junio C Hamano <junkio@cox.net>
+From:  Junio C Hamano <gitster@pobox.com>
 To:    git@vger.kernel.org
 Cc:    Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
 Subject: Re: sending changesets from the middle of a git tree
@@ -8,17 +8,23 @@ Abstract: In this article, JC talks about how he rebases the
  the "master" branch, and how "rebase" works.  Also discussed
  is how this applies to individual developers who sends patches
  upstream.
+Content-type: text/asciidoc
 
+How to rebase from an internal branch
+=====================================
+
+--------------------------------------
 Petr Baudis <pasky@suse.cz> writes:
 
 > Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
 > where Junio C Hamano <junkio@cox.net> told me that...
 >> Linus Torvalds <torvalds@osdl.org> writes:
->> 
->> > Junio, maybe you want to talk about how you move patches from your "pu" 
+>>
+>> > Junio, maybe you want to talk about how you move patches from your "pu"
 >> > branch to the real branches.
->> 
+>>
 > Actually, wouldn't this be also precisely for what StGIT is intended to?
+--------------------------------------
 
 Exactly my feeling.  I was sort of waiting for Catalin to speak
 up.  With its basing philosophical ancestry on quilt, this is
@@ -27,7 +33,7 @@ the kind of task StGIT is designed to do.
 I just have done a simpler one, this time using only the core
 GIT tools.
 
-I had a handful commits that were ahead of master in pu, and I
+I had a handful of commits that were ahead of master in pu, and I
 wanted to add some documentation bypassing my usual habit of
 placing new things in pu first.  At the beginning, the commit
 ancestry graph looked like this:
@@ -106,7 +112,7 @@ prepare #2 and #3 for e-mail submission.
 
     $ git format-patch master^^ master
 
-This creates two files, 0001-XXXX.txt and 0002-XXXX.txt.  Send
+This creates two files, 0001-XXXX.patch and 0002-XXXX.patch.  Send
 them out "To: " your project maintainer and "Cc: " your mailing
 list.  You could use contributed script git-send-email if
 your host has necessary perl modules for this, but your usual
@@ -118,7 +124,7 @@ up your changes, along with other changes.
 
    where                      *your "master" head
   upstream --> #1 --> #2 --> #3
-    used   \ 
+    used   \
    to be     \--> #A --> #2' --> #3' --> #B --> #C
                                                 *upstream head
 
@@ -133,7 +139,7 @@ You fetch from upstream, but not merge.
     $ git fetch upstream
 
 This leaves the updated upstream head in .git/FETCH_HEAD but
-does not touch your .git/HEAD nor .git/refs/heads/master.  
+does not touch your .git/HEAD nor .git/refs/heads/master.
 You run "git rebase" now.
 
     $ git rebase FETCH_HEAD master
@@ -156,10 +162,3 @@ you continue on starting from the new "master" head, which is
 the #1' commit.
 
 -jc
-
--
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
-