$ git checkout mybranch $ echo "Work, work, work" >>hello -$ git commit -m 'Some work.' hello+$ git commit -m 'Some work.' -i hello
$ git checkout mybranch $ echo "Work, work, work" >>hello -$ git commit -m 'Some work.' hello+$ git commit -m 'Some work.' -i hello
Here, we just added another line to hello, and we used a shorthand for doing both git-update-index hello and git commit by just giving the @@ -1105,7 +1105,7 @@ hasn't happened in the master branch at all. Then do
$ echo "Play, play, play" >>hello $ echo "Lots of fun" >>example -$ git commit -m 'Some fun.' hello example+$ git commit -m 'Some fun.' -i hello example
since the master branch is obviously in a much better mood.
Now, you've got two branches, and you decide that you want to merge the @@ -1161,7 +1161,7 @@ Work, work, work
and once you're happy with your manual merge, just do a
$ git commit hello+
$ git commit -i hello
which will very loudly warn you that you're now committing a merge (which is correct, so never mind), and you can write a small merge @@ -2011,7 +2011,7 @@ to follow, not easier.
git-rerere - + Reuse recorded resolve +
+git-rerere
+In a workflow that employs relatively long lived topic branches, +the developer sometimes needs to resolve the same conflict over +and over again until the topic branches are done (either merged +to the "release" branch, or sent out and accepted upstream).
+This command helps this process by recording conflicted +automerge results and corresponding hand-resolve results on the +initial manual merge, and later by noticing the same automerge +results and applying the previously recorded hand resolution.
+|
+ Note
+ |
+You need to create $GIT_DIR/rr-cache directory to enable this +command. | +
When your topic branch modifies overlapping area that your +master branch (or upstream) touched since your topic branch +forked from it, you may want to test it with the latest master, +even before your topic branch is ready to be pushed upstream:
+o---*---o topic + / + o---o---o---*---o---o master+
For such a test, you need to merge master and topic somehow. +One way to do it is to pull master into the topic branch:
+$ git checkout topic + $ git pull . master + + o---*---o---+ topic + / / + o---o---o---*---o---o master+
The commits marked with * touch the same area in the same +file; you need to resolve the conflicts when creating the commit +marked with +. Then you can test the result to make sure your +work-in-progress still works with what is in the latest master.
+After this test merge, there are two ways to continue your work +on the topic. The easiest is to build on top of the test merge +commit +, and when your work in the topic branch is finally +ready, pull the topic branch into master, and/or ask the +upstream to pull from you. By that time, however, the master or +the upstream might have been advanced since the test merge +, +in which case the final commit graph would look like this:
+$ git checkout topic + $ git pull . master + $ ... work on both topic and master branches + $ git checkout master + $ git pull . topic + + o---*---o---+---o---o topic + / / \ + o---o---o---*---o---o---o---o---+ master+
When your topic branch is long-lived, however, your topic branch +would end up having many such "Merge from master" commits on it, +which would unnecessarily clutter the development history. +Readers of the Linux kernel mailing list may remember that Linus +complained about such too frequent test merges when a subsystem +maintainer asked to pull from a branch full of "useless merges".
+As an alternative, to keep the topic branch clean of test +merges, you could blow away the test merge, and keep building on +top of the tip before the test merge:
+$ git checkout topic + $ git pull . master + $ git reset --hard HEAD^ ;# rewind the test merge + $ ... work on both topic and master branches + $ git checkout master + $ git pull . topic + + o---*---o-------o---o topic + / \ + o---o---o---*---o---o---o---o---+ master+
This would leave only one merge commit when your topic branch is +finally ready and merged into the master branch. This merge +would require you to resolve the conflict, introduced by the +commits marked with *. However, often this conflict is the +same conflict you resolved when you created the test merge you +blew away. git-rerere command helps you to resolve this final +conflicted merge using the information from your earlier hand +resolve.
+Running git-rerere command immediately after a conflicted +automerge records the conflicted working tree files, with the +usual conflict markers <<<<<<<, =======, and >>>>>>> in +them. Later, after you are done resolving the conflicts, +running git-rerere again records the resolved state of these +files. Suppose you did this when you created the test merge of +master into the topic branch.
+Next time, running git-rerere after seeing a conflicted +automerge, if the conflict is the same as the earlier one +recorded, it is noticed and a three-way merge between the +earlier conflicted automerge, the earlier manual resolution, and +the current conflicted automerge is performed by the command. +If this three-way merge resolves cleanly, the result is written +out to your working tree file, so you would not have to manually +resolve it. Note that git-rerere leaves the index file alone, +so you still need to do the final sanity checks with git diff +(or git diff -c) and git update-index when you are +satisfied.
+As a convenience measure, git-merge automatically invokes +git-rerere when it exits with a failed automerge, which +records it if it is a new conflict, or reuses the earlier hand +resolve when it is not. git-commit also invokes git-rerere +when recording a merge result. What this means is that you do +not have to do anything special yourself (Note: you still have +to create $GIT_DIR/rr-cache directory to enable this command).
+In our example, when you did the test merge, the manual +resolution is recorded, and it will be reused when you do the +actual merge later with updated master and topic branch, as long +as the earlier resolution is still applicable.
+The information git-rerere records is also used when running +git-rebase. After blowing away the test merge and continuing +development on the topic branch:
+o---*---o-------o---o topic + / + o---o---o---*---o---o---o---o master + + $ git rebase master topic + + o---*---o-------o---o topic + / + o---o---o---*---o---o---o---o master+
you could run git rebase master topic, to keep yourself +up-to-date even before your topic is ready to be sent upstream. +This would result in falling back to three-way merge, and it +would conflict the same way the test merge you resolved earlier. +git-rerere is run by git rebase to help you resolve this +conflict.
+Written by Junio C Hamano <junkio@cox.net>
+Part of the git(7) suite
+