aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2015-06-17 16:28:53 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2015-06-17 16:28:53 +0200
commit5bbf5c57b04897b68dd9e37734a3f4cc1d82d45b (patch)
treeebab4617acd098556320d158d6e07aa2e590eecd
parentf668da82494983a2ae2c7f8c160ec1a109d335b8 (diff)
Add note on rebase/rerere
-rw-r--r--cheatsheet.txt43
1 files changed, 41 insertions, 2 deletions
diff --git a/cheatsheet.txt b/cheatsheet.txt
index 3a66a5b..958c8cc 100644
--- a/cheatsheet.txt
+++ b/cheatsheet.txt
@@ -94,8 +94,47 @@ History Cleanup
git merge master
git rebase master
- At this stage, run gitk and verify that you now have a linear history
- that starts with master.
+ The last step ('git rebase') is where the rerere machinery mentioned
+ earlier may have to come to play and if you didn't have it enabled
+ during the development of, things may not go very smoothly and we
+ need this side note: in general, rebase is no magic, what it does is
+ take the patches from commits that you have and try to replay them
+ on top of your new base, resolving conflicts just like merge does.
+
+ So, if during development of your feature branch you had a merge
+ conflicts that you had to manually resolve, then you will have
+ merge conflicts during rebase that you will have to resolve as
+ well.
+
+ This is where rerere comes in. What it does is record your conflict
+ resolutions when you first manually resolved them during your feature
+ branch development. When later, during rebase, it sees that the same
+ conflict is being resolved during rebase, it automatically applies
+ the stored resolution. So if you didn't have rerere enabled from the
+ beginning, this should explain why things didn't go smoothly for you:
+ since you didn't have rerere enabled during your earlier merges, it
+ didn't record the resolutions. And in this case what you would have
+ gotten is a normal merge conflict, just like the first time, that
+ you have to resolve manually again.
+
+ Running 'git stat' should give you the idea of what needs fixing. Once
+ you have edit the files, run 'git add' and then 'git rebase --continue'.
+
+ Now, a note on rerere: again, it is kind of magic but not exactly.
+ Specifically, it doesn't hide this whole process from you. Instead, it
+ applies the conflict resolution that it has stored from earlier but
+ stops for you to confirm that all is good. So what normally happens
+ is that you still get the rebase merge conflict except that it applies
+ the resolution and there is a message in git rebase output to this
+ effect. Now you need to review it (e.g., with gitk), run 'git add'
+ to confirm it's good, and then run 'git rebase --continue'. And of
+ the side node.
+
+ If you managed to get through all this, run gitk and verify that you
+ now have a linear history that starts with master. If things got
+ hairy along the way, you may want to verify that the end result,
+ content-wise, is exactly the same as what you have started with
+ by diff'ing with the backup you have made at the beginning.
The second step is to clean up the commit history of our feature
branch since it may have "dirty", work-in-progress commits. This may