unpack-trees.c: assume submodules are clean during check-out
[gitweb.git] / Documentation / git-rerere.txt
index 8b6b6512371fd67fbb56d06cf29e826d3ef69d56..c4d4263238e5b7c6dff705de5d8552a577fc35d6 100644 (file)
@@ -3,12 +3,11 @@ git-rerere(1)
 
 NAME
 ----
-git-rerere - Reuse recorded resolve
+git-rerere - Reuse recorded resolution of conflicted merges
 
 SYNOPSIS
 --------
-'git-rerere'
-
+'git-rerere' [clear|diff|status|gc]
 
 DESCRIPTION
 -----------
@@ -24,9 +23,45 @@ 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
+You need to set the config variable rerere.enabled to enable this
 command.
 
+
+COMMANDS
+--------
+
+Normally, git-rerere is run without arguments or user-intervention.
+However, it has several commands that allow it to interact with
+its working state.
+
+'clear'::
+
+This resets the metadata used by rerere if a merge resolution is to be
+is aborted.  Calling gitlink:git-am[1] --skip or gitlink:git-rebase[1]
+[--skip|--abort] will automatically invoke this command.
+
+'diff'::
+
+This displays diffs for the current state of the resolution.  It is
+useful for tracking what has changed while the user is resolving
+conflicts.  Additional arguments are passed directly to the system
+diff(1) command installed in PATH.
+
+'status'::
+
+Like diff, but this only prints the filenames that will be tracked
+for resolutions.
+
+'gc'::
+
+This command is used to prune records of conflicted merge that
+occurred long time ago.  By default, conflicts older than 15
+days that you have not recorded their resolution, and conflicts
+older than 60 days, are pruned.  These are controlled with
+`gc.rerereunresolved` and `gc.rerereresolved` configuration
+variables.
+
+
 DISCUSSION
 ----------
 
@@ -46,7 +81,7 @@ One way to do it is to pull master into the topic branch:
 
 ------------
        $ git checkout topic
-       $ git pull . master
+       $ git merge master
 
               o---*---o---+ topic
              /           /
@@ -68,10 +103,10 @@ in which case the final commit graph would look like this:
 
 ------------
        $ git checkout topic
-       $ git pull . master
+       $ git merge master
        $ ... work on both topic and master branches
        $ git checkout master
-       $ git pull . topic
+       $ git merge topic
 
               o---*---o---+---o---o topic
              /           /         \
@@ -91,11 +126,11 @@ top of the tip before the test merge:
 
 ------------
        $ git checkout topic
-       $ git pull . master
+       $ git merge master
        $ git reset --hard HEAD^ ;# rewind the test merge
        $ ... work on both topic and master branches
        $ git checkout master
-       $ git pull . topic
+       $ git merge topic
 
               o---*---o-------o---o topic
              /                     \
@@ -128,8 +163,7 @@ 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.
+(or `git diff -c`) and `git add` when you are satisfied.
 
 As a convenience measure, `git-merge` automatically invokes
 `git-rerere` when it exits with a failed automerge, which
@@ -137,7 +171,7 @@ 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).
+to set the config variable rerere.enabled 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