Documentation: shared repository management in tutorial.

[git.git] / Documentation / howto / rebase-from-internal-branch.txt

diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
index 8109b7f..c2d4a91 100644 (file)
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -3,6 +3,11 @@ 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
 Date:  Sun, 14 Aug 2005 18:37:39 -0700
 Cc:    Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
 Subject: Re: sending changesets from the middle of a git tree
 Date:  Sun, 14 Aug 2005 18:37:39 -0700

+Abstract: In this article, JC talks about how he rebases the
+ public "pu" branch using the core GIT tools when he updates
+ the "master" branch, and how "rebase" works.  Also discussed
+ is how this applies to individual developers who sends patches
+ upstream.

 
 Petr Baudis <pasky@suse.cz> writes:
 
 
 Petr Baudis <pasky@suse.cz> writes:
 


@@ -33,12 +38,9 @@ ancestry graph looked like this:
 So I started from master, made a bunch of edits, and committed:
 
     $ git checkout master
 So I started from master, made a bunch of edits, and committed:
 
     $ git checkout master

-    $ cd Documentation; ed git.txt git-apply-patch-script.txt ...
+    $ cd Documentation; ed git.txt ...

     $ cd ..; git add Documentation/*.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:
 
 
 After the commit, the ancestry graph would look like this:
 


@@ -93,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
 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
 
                               *your "master" head
    upstream --> #1 --> #2 --> #3


@@ -106,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
 
 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.
 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.