about summary refs log tree commit diff
path: root/third_party/git/Documentation/howto/rebase-from-internal-branch.txt
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/git/Documentation/howto/rebase-from-internal-branch.txt')
-rw-r--r--third_party/git/Documentation/howto/rebase-from-internal-branch.txt164
1 files changed, 0 insertions, 164 deletions
diff --git a/third_party/git/Documentation/howto/rebase-from-internal-branch.txt b/third_party/git/Documentation/howto/rebase-from-internal-branch.txt
deleted file mode 100644
index f2e10a7ec886..000000000000
--- a/third_party/git/Documentation/howto/rebase-from-internal-branch.txt
+++ /dev/null
@@ -1,164 +0,0 @@
-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
-Date:	Sun, 14 Aug 2005 18:37:39 -0700
-Abstract: In this article, JC talks about how he rebases the
- public "seen" 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.
-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
->> > "seen" 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
-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 of commits that were ahead of master in 'seen', and I
-wanted to add some documentation bypassing my usual habit of
-placing new things in 'seen' first.  At the beginning, the commit
-ancestry graph looked like this:
-
-			     *"seen" head
-    master --> #1 --> #2 --> #3
-
-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
-
-After the commit, the ancestry graph would look like this:
-
-			      *"seen" head
-    master^ --> #1 --> #2 --> #3
-          \
-            \---> master
-
-The old master is now master^ (the first parent of the master).
-The new master commit holds my documentation updates.
-
-Now I have to deal with "seen" branch.
-
-This is the kind of situation I used to have all the time when
-Linus was the maintainer and I was a contributor, when you look
-at "master" branch being the "maintainer" branch, and "seen"
-branch being the "contributor" branch.  Your work started at the
-tip of the "maintainer" branch some time ago, you made a lot of
-progress in the meantime, and now the maintainer branch has some
-other commits you do not have yet.  And "git rebase" was written
-with the explicit purpose of helping to maintain branches like
-"seen".  You _could_ merge master to 'seen' and keep going, but if you
-eventually want to cherrypick and merge some but not necessarily
-all changes back to the master branch, it often makes later
-operations for _you_ easier if you rebase (i.e. carry forward
-your changes) "seen" rather than merge.  So I ran "git rebase":
-
-    $ git checkout seen
-    $ git rebase master seen
-
-What this does is to pick all the commits since the current
-branch (note that I now am on "seen" branch) forked from the
-master branch, and forward port these changes.
-
-    master^ --> #1 --> #2 --> #3
-	  \                                  *"seen" head
-            \---> master --> #1' --> #2' --> #3'
-
-The diff between master^ and #1 is applied to master and
-committed to create #1' commit with the commit information (log,
-author and date) taken from commit #1.  On top of that #2' and #3'
-commits are made similarly out of #2 and #3 commits.
-
-Old #3 is not recorded in any of the .git/refs/heads/ file
-anymore, so after doing this you will have dangling commit if
-you ran fsck-cache, which is normal.  After testing "seen", you
-can run "git prune" to get rid of those original three commits.
-
-While I am talking about "git rebase", I should talk about how
-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
-made a couple of commits on top of it.
-
-                              *your "master" head
-   upstream --> #1 --> #2 --> #3
-
-You would want changes #2 and #3 incorporated in the upstream,
-while you feel that #1 may need further improvements.  So you
-prepare #2 and #3 for e-mail submission.
-
-    $ git format-patch master^^ master
-
-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
-MUA would do as long as it does not corrupt whitespaces in the
-patch.
-
-Then you would wait, and you find out that the upstream picked
-up your changes, along with other changes.
-
-   where                      *your "master" head
-  upstream --> #1 --> #2 --> #3
-    used   \
-   to be     \--> #A --> #2' --> #3' --> #B --> #C
-                                                *upstream head
-
-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 upstream
-maintainer and definitely with different committer and ancestry
-information, they are different objects from #2 and #3 commits.
-
-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 or .git/refs/heads/master.
-You run "git rebase" now.
-
-    $ git rebase FETCH_HEAD master
-
-Earlier, I said that rebase applies all the commits from your
-branch on top of the upstream head.  Well, I lied.  "git rebase"
-is a bit smarter than that and notices that #2 and #3 need not
-be applied, so it only applies #1.  The commit ancestry graph
-becomes something like this:
-
-   where                     *your old "master" head
-  upstream --> #1 --> #2 --> #3
-    used   \                      your new "master" head*
-   to be     \--> #A --> #2' --> #3' --> #B --> #C --> #1'
-                                                *upstream
-                                                head
-
-Again, "git prune" would discard the disused commits #1-#3 and
-you continue on starting from the new "master" head, which is
-the #1' commit.
-
--jc