{"thread":{"id":"29304","subject":"[PATCH] Documentation: rerere.enabled overrides [ -d rr-cache ]","startedAt":"2012-01-06T13:08:02Z","lastAt":"2012-01-10T14:57:27Z","messageCount":5,"participants":["Thomas Rast","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"182017","messageId":"f697b8eff63a8cdd1207c6bfd6b88c532832c6b5.1325855112.git.trast@student.ethz.ch","threadId":"29304","inReplyTo":null,"subject":"[PATCH] Documentation: rerere.enabled overrides [ -d rr-cache ]","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-06T13:08:02Z","receivedAt":"2012-01-06T13:08:02Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"The wording seems to suggest that you can only globally disable rerere\nwith the rerere.enabled setting. But the code actually consults the\nconfig first, and even creates rr-cache for the user if needed.\n\nSigned-off-by: Thomas Rast \n---\n\nNoticed while discussing rerere on IRC. \"Can be disabled by setting\nthis option to false\" is of course correct, but insinuates that\nsetting it to 'true' still falls back to rr-cache, which it doesn't.\n\ngit-rerere(1) does not mention the rr-cache fallback; I decided not to\ntouch it as it's a bit of an implementation detail. OTOH the\nauto-creation of rr-cache can cause strange behavior if a user has\nrerere.enabled unset and tries it once, as in\n\n git config rerere.enabled true\n git merge ...\n git config --unset rerere.enabled\n\n\n Documentation/config.txt | 8 ++++----\n 1 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 68cf702..04f5e19 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1783,10 +1783,10 @@ rerere.autoupdate::\n \n rerere.enabled::\n \tActivate recording of resolved conflicts, so that identical\n-\tconflict hunks can be resolved automatically, should they\n-\tbe encountered again. linkgit:git-rerere[1] command is by\n-\tdefault enabled if you create `rr-cache` directory under\n-\t`$GIT_DIR`, but can be disabled by setting this option to false.\n+\tconflict hunks can be resolved automatically, should they be\n+\tencountered again. By default, linkgit:git-rerere[1] is\n+\tenabled if there is an `rr-cache` directory under the\n+\t`$GIT_DIR`.\n \n sendemail.identity::\n \tA configuration identity. When given, causes values in the\n-- \n1.7.8.2.479.g7c686\n"},{"id":"182040","messageId":"7vfwfsk24y.fsf@alter.siamese.dyndns.org","threadId":"29304","inReplyTo":"f697b8eff63a8cdd1207c6bfd6b88c532832c6b5.1325855112.git.trast@student.ethz.ch","subject":"Re: [PATCH] Documentation: rerere.enabled overrides [ -d rr-cache ]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-06T20:27:25Z","receivedAt":"2012-01-06T20:27:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> git-rerere(1) does not mention the rr-cache fallback; I decided not to\n> touch it as it's a bit of an implementation detail.\n\nIt is not an implementation detail but is a (n old) part of the external\nUI. Creating .git/rr-cache directory has been the only way to enable it\nfor quite a while (ever since it was first written as a Perl script early\n2006, and the design even survived the rewrite in C late 2006). When the\nconfiguration variable rerere.enabled was introduced with b4372ef (Enable\n\"git rerere\" by the config variable rerere.enabled, 2007-07-06), we\ndeliberately kept the external interface compatible to avoid disruption.\n\nAnd your \"By default, ... is enabled if there is ... directory\" below is\nexactly the right description.\n\nThe manual page for \"rerere\" talks about \"configuration variable\nrerere.enabled\"; perhaps it should also refer to git config manual page to\nmake it more discoverable?\n\n> ... OTOH the\n> auto-creation of rr-cache can cause strange behavior if a user has\n> rerere.enabled unset and tries it once, as in\n>\n> git config rerere.enabled true\n> git merge ...\n> git config --unset rerere.enabled\n\nThat is because the last one should be\n\n\tgit config --bool rerere.enabled false\n\nPerhaps the description for \"--unset\" option in the manual of \"git config\"\nis not clear enough that there is a difference between a variable not\nbeing set (i.e. we do not know anything about what the user wants) and a\nvariable explicitly set to false (i.e. we do know the user does not want\nit)? I doubt it, but you may want to check and clarify the section if\nneeded.\n\nThe patch itself looks good; it goes in the right direction.\n\nThanks.\n\n> Documentation/config.txt | 8 ++++----\n> 1 files changed, 4 insertions(+), 4 deletions(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 68cf702..04f5e19 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1783,10 +1783,10 @@ rerere.autoupdate::\n> \n> rerere.enabled::\n> \tActivate recording of resolved conflicts, so that identical\n> -\tconflict hunks can be resolved automatically, should they\n> -\tbe encountered again. linkgit:git-rerere[1] command is by\n> -\tdefault enabled if you create `rr-cache` directory under\n> -\t`$GIT_DIR`, but can be disabled by setting this option to false.\n> +\tconflict hunks can be resolved automatically, should they be\n> +\tencountered again. By default, linkgit:git-rerere[1] is\n> +\tenabled if there is an `rr-cache` directory under the\n> +\t`$GIT_DIR`.\n> \n> sendemail.identity::\n> \tA configuration identity. When given, causes values in the\n"},{"id":"182053","messageId":"87boqge19s.fsf@thomas.inf.ethz.ch","threadId":"29304","inReplyTo":"7vfwfsk24y.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: rerere.enabled overrides [ -d rr-cache ]","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-07T01:42:39Z","receivedAt":"2012-01-07T01:42:39Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> The manual page for \"rerere\" talks about \"configuration variable\n> rerere.enabled\"; perhaps it should also refer to git config manual page to\n> make it more discoverable?\n\nMaybe, but it already says you should set the variable in two different\nplaces.\n\n> Thomas Rast writes:\n>\n>> ... OTOH the\n>> auto-creation of rr-cache can cause strange behavior if a user has\n>> rerere.enabled unset and tries it once, as in\n>>\n>> git config rerere.enabled true\n>> git merge ...\n>> git config --unset rerere.enabled\n>\n> That is because the last one should be\n>\n> \tgit config --bool rerere.enabled false\n\nI definitely meant --unset. If the user knows the distinction, and\nwants to return the variable to the state it had before his test\n(perhaps so that a future --global setting might take effect), he would\nuse this sequence. He might then be somewhat surprised to see that\nrerere is now permamently enabled for this repo.\n\nProbably I'm worrying too much about a weird fringe case though.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"182058","messageId":"7vk454gkh3.fsf@alter.siamese.dyndns.org","threadId":"29304","inReplyTo":"87boqge19s.fsf@thomas.inf.ethz.ch","subject":"Re: [PATCH] Documentation: rerere.enabled overrides [ -d rr-cache ]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-07T05:17:12Z","receivedAt":"2012-01-07T05:17:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Junio C Hamano writes:\n>\n>> The manual page for \"rerere\" talks about \"configuration variable\n>> rerere.enabled\"; perhaps it should also refer to git config manual page to\n>> make it more discoverable?\n>\n> Maybe, but it already says you should set the variable in two different\n> places.\n\nThat is not the point.\n\nThe documentation for git config seems to be the only place where we\nexplain that the existence of rr-cache determines what happens when the\nuser does _not_ set the variable; lack of that description will lead to\nthe confusion you describe below:\n\n>> Thomas Rast writes:\n>>\n>>> ... OTOH the\n>>> auto-creation of rr-cache can cause strange behavior if a user has\n>>> rerere.enabled unset and tries it once, as in\n>>>\n>>> git config rerere.enabled true\n>>> git merge ...\n>>> git config --unset rerere.enabled\n>>\n>> That is because the last one should be\n>>\n>> \tgit config --bool rerere.enabled false\n>\n> I definitely meant --unset. If the user knows the distinction, and\n> wants to return the variable to the state it had before his test ...\n\nRunning \"unset\" is how to return the _variable_ to the previous state, but\nthat is _not_ how to return to the previous state of the _repository_.\n\nPerhaps something like this in addition?\n\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 04f5e19..c523c67 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1786,7 +1786,8 @@ rerere.enabled::\n \tconflict hunks can be resolved automatically, should they be\n \tencountered again. By default, linkgit:git-rerere[1] is\n \tenabled if there is an `rr-cache` directory under the\n-\t`$GIT_DIR`.\n+\t`$GIT_DIR`, e.g. if \"rerere\" was previously used in the\n+\trepository.\n \n sendemail.identity::\n \tA configuration identity. When given, causes values in the\n"},{"id":"182240","messageId":"87aa5vd2qw.fsf@thomas.inf.ethz.ch","threadId":"29304","inReplyTo":"7vk454gkh3.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: rerere.enabled overrides [ -d rr-cache ]","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-10T14:57:27Z","receivedAt":"2012-01-10T14:57:27Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Sorry I'm late, but...\n\nOn Fri, 6 Jan 2012 21:17:12 -0800, Junio C Hamano wrote:\n> \n> Running \"unset\" is how to return the _variable_ to the previous state, but\n> that is _not_ how to return to the previous state of the _repository_.\n> \n> Perhaps something like this in addition?\n[...]\n> \tencountered again. By default, linkgit:git-rerere[1] is\n> \tenabled if there is an `rr-cache` directory under the\n> -\t`$GIT_DIR`.\n> +\t`$GIT_DIR`, e.g. if \"rerere\" was previously used in the\n> +\trepository.\n\nI don't feel strongly about it, but this is a really neat and concise\nway to put it, so why not. Here's hoping I can save you some work:\n\n---- 8< ---- 8< ----\nFrom: Junio C Hamano \nSubject: Documentation: rerere's rr-cache auto-creation and rerere.enabled\n\nThe description of rerere.enabled left the user in the dark as to who\nmight create an rr-cache directory. Add a note that simply invoking\nrerere does this.\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 04f5e19..c523c67 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1786,7 +1786,8 @@ rerere.enabled::\n \tconflict hunks can be resolved automatically, should they be\n \tencountered again. By default, linkgit:git-rerere[1] is\n \tenabled if there is an `rr-cache` directory under the\n-\t`$GIT_DIR`.\n+\t`$GIT_DIR`, e.g. if \"rerere\" was previously used in the\n+\trepository.\n \n sendemail.identity::\n \tA configuration identity. When given, causes values in the\n\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"}]}