The wording seems to suggest that you can only globally disable rerere with the rerere.enabled setting. But the code actually consults the config first, and even creates rr-cache for the user if needed. Signed-off-by: Thomas Rast <trast@xxxxxxxxxxxxxxx> --- Noticed while discussing rerere on IRC. "Can be disabled by setting this option to false" is of course correct, but insinuates that setting it to 'true' still falls back to rr-cache, which it doesn't. git-rerere(1) does not mention the rr-cache fallback; I decided not to touch it as it's a bit of an implementation detail. OTOH the auto-creation of rr-cache can cause strange behavior if a user has rerere.enabled unset and tries it once, as in git config rerere.enabled true git merge ... git config --unset rerere.enabled Documentation/config.txt | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 68cf702..04f5e19 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1783,10 +1783,10 @@ rerere.autoupdate:: rerere.enabled:: Activate recording of resolved conflicts, so that identical - conflict hunks can be resolved automatically, should they - be encountered again. linkgit:git-rerere[1] command is by - default enabled if you create `rr-cache` directory under - `$GIT_DIR`, but can be disabled by setting this option to false. + conflict hunks can be resolved automatically, should they be + encountered again. By default, linkgit:git-rerere[1] is + enabled if there is an `rr-cache` directory under the + `$GIT_DIR`. sendemail.identity:: A configuration identity. When given, causes values in the -- 1.7.8.2.479.g7c686 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html