Merge git://git.kernel.org/pub/scm/gitk/gitk
[gitweb.git] / Documentation / howto / rebase-from-internal-branch.txt
index 4523b69d4fc018a67835e0751f08c9be17635d65..fcd64e9b9b6d53b46d31e0c797016e9881651604 100644 (file)
@@ -40,10 +40,7 @@ So I started from master, made a bunch of edits, and committed:
     $ git checkout master
     $ cd Documentation; ed git.txt ...
     $ cd ..; git add Documentation/*.txt
-    $ git commit -s -v
-
-NOTE.  The -v flag to commit is a handy way to make sure that
-your additions are not introducing bogusly formatted lines.
+    $ git commit -s
 
 After the commit, the ancestry graph would look like this:
 
@@ -98,7 +95,7 @@ to do cherrypicking using only the core GIT tools.
 Let's go back to the earlier picture, with different labels.
 
 You, as an individual developer, cloned upstream repository and
-amde a couple of commits on top of it.
+made a couple of commits on top of it.
 
                               *your "master" head
    upstream --> #1 --> #2 --> #3
@@ -111,7 +108,7 @@ prepare #2 and #3 for e-mail submission.
 
 This creates two files, 0001-XXXX.txt and 0002-XXXX.txt.  Send
 them out "To: " your project maintainer and "Cc: " your mailing
-list.  You could use contributed script git-send-email-script if
+list.  You could use contributed script git-send-email if
 your host has necessary perl modules for this, but your usual
 MUA would do as long as it does not corrupt whitespaces in the
 patch.
@@ -127,7 +124,7 @@ up your changes, along with other changes.
 
 The two commits #2' and #3' in the above picture record the same
 changes your e-mail submission for #2 and #3 contained, but
-probably with the new sign-off line added by the upsteam
+probably with the new sign-off line added by the upstream
 maintainer and definitely with different committer and ancestry
 information, they are different objects from #2 and #3 commits.