diff options
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.txt | 164 |
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 |