{"thread":{"id":"38453","subject":"[PATCH] Documentation/git-add.txt: add `add.ginore-errors` configuration variable","startedAt":"2015-01-26T16:55:25Z","lastAt":"2015-02-02T18:54:22Z","messageCount":16,"participants":["Alexander Kuleshov","Eric Sunshine","Junio C Hamano","Michael Haggerty","Jeff King","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"255295","messageId":"1422291325-4332-1-git-send-email-kuleshovmail@gmail.com","threadId":"38453","inReplyTo":null,"subject":"[PATCH] Documentation/git-add.txt: add `add.ginore-errors` configuration variable","fromName":"Alexander Kuleshov","fromEmail":"kuleshovmail@gmail.com","sentAt":"2015-01-26T16:55:25Z","receivedAt":"2015-01-26T16:55:25Z","isPatch":true,"sender":{"key":"kuleshovmail@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2699235?v=4"},"body":"'git add' supports not only `add.ignoreErrors`, but also `add.ignore-errors`\nconfiguration variable.\n\nSigned-off-by: Alexander Kuleshov \n---\n Documentation/git-add.txt | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex 1c74907..f68c2a2 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -155,8 +155,8 @@ for \"git add --no-all ...\", i.e. ignored removed files.\n \tIf some files could not be added because of errors indexing\n \tthem, do not abort the operation, but continue adding the\n \tothers. The command shall still exit with non-zero status.\n-\tThe configuration variable `add.ignoreErrors` can be set to\n-\ttrue to make this the default behaviour.\n+\tThe configuration variable `add.ignoreErrors` or `add.ignore-errors`\n+\tcan be set to true to make this the default behaviour.\n \n --ignore-missing::\n \tThis option can only be used together with --dry-run. By using\n-- \n2.3.0.rc1.275.g028c360\n"},{"id":"255309","messageId":"CAPig+cT9hC=n7WkANno9Eif-+RUCeA6mQioUhOSkDEx_vdmN1Q@mail.gmail.com","threadId":"38453","inReplyTo":"1422291325-4332-1-git-send-email-kuleshovmail@gmail.com","subject":"Re: [PATCH] Documentation/git-add.txt: add `add.ginore-errors` configuration variable","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-01-26T21:58:20Z","receivedAt":"2015-01-26T21:58:20Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Jan 26, 2015 at 11:55 AM, Alexander Kuleshov\n wrote:\n> 'git add' supports not only `add.ignoreErrors`, but also `add.ignore-errors`\n> configuration variable.\n\nSee 6b3020a2 (add: introduce add.ignoreerrors synonym for\nadd.ignore-errors, 2010-12-01) for why this patch is undesirable.\n\n> Signed-off-by: Alexander Kuleshov \n> ---\n> Documentation/git-add.txt | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\n> index 1c74907..f68c2a2 100644\n> --- a/Documentation/git-add.txt\n> +++ b/Documentation/git-add.txt\n> @@ -155,8 +155,8 @@ for \"git add --no-all ...\", i.e. ignored removed files.\n> If some files could not be added because of errors indexing\n> them, do not abort the operation, but continue adding the\n> others. The command shall still exit with non-zero status.\n> - The configuration variable `add.ignoreErrors` can be set to\n> - true to make this the default behaviour.\n> + The configuration variable `add.ignoreErrors` or `add.ignore-errors`\n> + can be set to true to make this the default behaviour.\n>\n> --ignore-missing::\n> This option can only be used together with --dry-run. By using\n> --\n> 2.3.0.rc1.275.g028c360\n"},{"id":"255344","messageId":"xmqqiofskmfd.fsf@gitster.dls.corp.google.com","threadId":"38453","inReplyTo":"CAPig+cT9hC=n7WkANno9Eif-+RUCeA6mQioUhOSkDEx_vdmN1Q@mail.gmail.com","subject":"Re: [PATCH] Documentation/git-add.txt: add `add.ginore-errors` configuration variable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-27T20:17:58Z","receivedAt":"2015-01-27T20:17:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> On Mon, Jan 26, 2015 at 11:55 AM, Alexander Kuleshov\n> wrote:\n>> 'git add' supports not only `add.ignoreErrors`, but also `add.ignore-errors`\n>> configuration variable.\n>\n> See 6b3020a2 (add: introduce add.ignoreerrors synonym for\n> add.ignore-errors, 2010-12-01) for why this patch is undesirable.\n\nWe might want to do this instead, as the correction to the\nmisspelled configuration variable name was from the 1.7.0-era that\nis sufficiently old (v1.7.0.8 was done in December 2010).\n\n-- >8 --\nSubject: doc: clarify naming rules for configuration variables\n\nAlso mark deprecated variables in the documentation more clearly.\n\nThe text for the rules are partly taken from the log message of\nJonathan's 6b3020a2 (add: introduce add.ignoreerrors synonym for\nadd.ignore-errors, 2010-12-01).\n\nSigned-off-by: Junio C Hamano \n---\n Documentation/CodingGuidelines | 25 +++++++++++++++++++++++++\n Documentation/config.txt | 15 +++++++--------\n 2 files changed, 32 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\nindex 894546d..8fbac15 100644\n--- a/Documentation/CodingGuidelines\n+++ b/Documentation/CodingGuidelines\n@@ -413,6 +413,31 @@ Error Messages\n - Say what the error is first (\"cannot open %s\", not \"%s: cannot open\")\n \n \n+Externally Visible Names\n+\n+ - For configuration variable names, follow the existing convention:\n+\n+ . The section name indicates the affected subsystem.\n+\n+ . The subsection name, if any, indicates which of an unbounded set\n+ of things to set the value for.\n+\n+ . The variable name describes the effect of tweaking this knob.\n+\n+ The section and variable names that consist of multiple words are\n+ formed by concatenating the words without punctuations (e.g. `-`),\n+ and are broken using bumpyCaps in documentation as a hint to the\n+ reader.\n+\n+ When choosing the variable namespace, do not use variable name for\n+ specifying possibly unbounded set of things, most notably anything\n+ an end user can freely come up with (e.g. branch names), but also\n+ large fixed set defined by the system that can grow over time\n+ (e.g. what kind of common whitespace problems to notice). Use\n+ subsection names or variable values, like existing variables\n+ branch..description and core.whitespace do, instead.\n+\n+\n Writing Documentation:\n \n Most (if not all) of the documentation pages are written in the\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 0a4d22a..8a76d1d 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -664,14 +664,13 @@ core.abbrev::\n \tfor abbreviated object names to stay unique for sufficiently long\n \ttime.\n \n-add.ignore-errors::\n add.ignoreErrors::\n+add.ignore-errors (deprecated)::\n \tTells 'git add' to continue adding files when some files cannot be\n \tadded due to indexing errors. Equivalent to the '--ignore-errors'\n-\toption of linkgit:git-add[1]. Older versions of Git accept only\n-\t`add.ignore-errors`, which does not follow the usual naming\n-\tconvention for configuration variables. Newer versions of Git\n-\thonor `add.ignoreErrors` as well.\n+\toption of linkgit:git-add[1]. `add.ignore-errors` is deprecated,\n+\tas it does not follow the usual naming convention for configuration\n+\tvariables.\n \n alias.*::\n \tCommand aliases for the linkgit:git[1] command wrapper - e.g.\n@@ -1924,7 +1923,7 @@ pack.useBitmaps::\n \ttrue. You should not generally need to turn this off unless\n \tyou are debugging pack bitmaps.\n \n-pack.writebitmaps::\n+pack.writebitmaps (deprecated)::\n \tThis is a deprecated synonym for `repack.writeBitmaps`.\n \n pack.writeBitmapHashCache::\n@@ -2235,7 +2234,7 @@ sendemail.smtpencryption::\n \tSee linkgit:git-send-email[1] for description. Note that this\n \tsetting is not subject to the 'identity' mechanism.\n \n-sendemail.smtpssl::\n+sendemail.smtpssl (deprecated)::\n \tDeprecated alias for 'sendemail.smtpencryption = ssl'.\n \n sendemail.smtpsslcertpath::\n@@ -2273,7 +2272,7 @@ sendemail.thread::\n sendemail.validate::\n \tSee linkgit:git-send-email[1] for description.\n \n-sendemail.signedoffcc::\n+sendemail.signedoffcc (deprecated)::\n \tDeprecated alias for 'sendemail.signedoffbycc'.\n \n showbranch.default::\n"},{"id":"255382","messageId":"1422484393-4414-1-git-send-email-gitster@pobox.com","threadId":"38453","inReplyTo":"xmqqiofskmfd.fsf@gitster.dls.corp.google.com","subject":"[PATCH 0/3] Documenting naming rules for configuration variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-28T22:33:10Z","receivedAt":"2015-01-28T22:33:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"So here is a rewrite of the same but split into three patches,\nafter seeing \"add.ignore-errors\" not marked exactly as deprecated.\n\nThe update to CodingGuidelines goes a bit beyond how to name things\n(i.e. bumpyCase vs dashed-words, the latter of which is strongly\ndiscouraged) but how the names should be structured (i.e. no\nunbounded set of things as variable names).\n\nWe may have to also be careful about underscores (there is one I\nknow about: gitweb.remote_heads that is used by instaweb), which\nmight be a good starter topic for somebody new to the codebase.\n\n\nJunio C Hamano (3):\n config.txt: clarify that add.ignore-errors is deprecated\n config.txt: mark deprecated variables more prominently\n CodingGuidelines: describe naming rules for configuration variables\n\n Documentation/CodingGuidelines | 25 +++++++++++++++++++++++++\n Documentation/config.txt | 15 +++++++--------\n 2 files changed, 32 insertions(+), 8 deletions(-)\n\n-- \n2.3.0-rc2-149-gdd42ee9\n"},{"id":"255380","messageId":"1422484393-4414-2-git-send-email-gitster@pobox.com","threadId":"38453","inReplyTo":"1422484393-4414-1-git-send-email-gitster@pobox.com","subject":"[PATCH 1/3] config.txt: clarify that add.ignore-errors is deprecated","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-28T22:33:11Z","receivedAt":"2015-01-28T22:33:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The old text gave an impression that even in a new repository using\nold form might be safer. Only Git from pre 1.7.0 days choke on the\ncorrectly named variable, which is ancient by today's standard.\n\nWe have no intention to remove the support for deprecated ones, but\nlet's make sure that we do not give room for confused questions such\nas \"why does core.sparse-checkout not work, when add.ignore-errors\ndoes?\"\n\nSigned-off-by: Junio C Hamano \n---\n Documentation/config.txt | 9 ++++-----\n 1 file changed, 4 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 0a4d22a..69f30d6 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -664,14 +664,13 @@ core.abbrev::\n \tfor abbreviated object names to stay unique for sufficiently long\n \ttime.\n \n-add.ignore-errors::\n add.ignoreErrors::\n+add.ignore-errors::\n \tTells 'git add' to continue adding files when some files cannot be\n \tadded due to indexing errors. Equivalent to the '--ignore-errors'\n-\toption of linkgit:git-add[1]. Older versions of Git accept only\n-\t`add.ignore-errors`, which does not follow the usual naming\n-\tconvention for configuration variables. Newer versions of Git\n-\thonor `add.ignoreErrors` as well.\n+\toption of linkgit:git-add[1]. `add.ignore-errors` is deprecated,\n+\tas it does not follow the usual naming convention for configuration\n+\tvariables.\n \n alias.*::\n \tCommand aliases for the linkgit:git[1] command wrapper - e.g.\n-- \n2.3.0-rc2-149-gdd42ee9\n"},{"id":"255381","messageId":"1422484393-4414-3-git-send-email-gitster@pobox.com","threadId":"38453","inReplyTo":"1422484393-4414-1-git-send-email-gitster@pobox.com","subject":"[PATCH 2/3] config.txt: mark deprecated variables more prominently","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-28T22:33:12Z","receivedAt":"2015-01-28T22:33:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Signed-off-by: Junio C Hamano \n---\n Documentation/config.txt | 8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 69f30d6..8a76d1d 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -665,7 +665,7 @@ core.abbrev::\n \ttime.\n \n add.ignoreErrors::\n-add.ignore-errors::\n+add.ignore-errors (deprecated)::\n \tTells 'git add' to continue adding files when some files cannot be\n \tadded due to indexing errors. Equivalent to the '--ignore-errors'\n \toption of linkgit:git-add[1]. `add.ignore-errors` is deprecated,\n@@ -1923,7 +1923,7 @@ pack.useBitmaps::\n \ttrue. You should not generally need to turn this off unless\n \tyou are debugging pack bitmaps.\n \n-pack.writebitmaps::\n+pack.writebitmaps (deprecated)::\n \tThis is a deprecated synonym for `repack.writeBitmaps`.\n \n pack.writeBitmapHashCache::\n@@ -2234,7 +2234,7 @@ sendemail.smtpencryption::\n \tSee linkgit:git-send-email[1] for description. Note that this\n \tsetting is not subject to the 'identity' mechanism.\n \n-sendemail.smtpssl::\n+sendemail.smtpssl (deprecated)::\n \tDeprecated alias for 'sendemail.smtpencryption = ssl'.\n \n sendemail.smtpsslcertpath::\n@@ -2272,7 +2272,7 @@ sendemail.thread::\n sendemail.validate::\n \tSee linkgit:git-send-email[1] for description.\n \n-sendemail.signedoffcc::\n+sendemail.signedoffcc (deprecated)::\n \tDeprecated alias for 'sendemail.signedoffbycc'.\n \n showbranch.default::\n-- \n2.3.0-rc2-149-gdd42ee9\n"},{"id":"255383","messageId":"1422484393-4414-4-git-send-email-gitster@pobox.com","threadId":"38453","inReplyTo":"1422484393-4414-1-git-send-email-gitster@pobox.com","subject":"[PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-28T22:33:13Z","receivedAt":"2015-01-28T22:33:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"We may want to say something about command line option names in the\nnew section as well, but for now, let's make sure everybody is clear\non how to structure and name their configuration variables.\n\nThe text for the rules are partly taken from the log message of\nJonathan's 6b3020a2 (add: introduce add.ignoreerrors synonym for\nadd.ignore-errors, 2010-12-01).\n\nSigned-off-by: Junio C Hamano \n---\n Documentation/CodingGuidelines | 25 +++++++++++++++++++++++++\n 1 file changed, 25 insertions(+)\n\ndiff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\nindex 894546d..8fbac15 100644\n--- a/Documentation/CodingGuidelines\n+++ b/Documentation/CodingGuidelines\n@@ -413,6 +413,31 @@ Error Messages\n - Say what the error is first (\"cannot open %s\", not \"%s: cannot open\")\n \n \n+Externally Visible Names\n+\n+ - For configuration variable names, follow the existing convention:\n+\n+ . The section name indicates the affected subsystem.\n+\n+ . The subsection name, if any, indicates which of an unbounded set\n+ of things to set the value for.\n+\n+ . The variable name describes the effect of tweaking this knob.\n+\n+ The section and variable names that consist of multiple words are\n+ formed by concatenating the words without punctuations (e.g. `-`),\n+ and are broken using bumpyCaps in documentation as a hint to the\n+ reader.\n+\n+ When choosing the variable namespace, do not use variable name for\n+ specifying possibly unbounded set of things, most notably anything\n+ an end user can freely come up with (e.g. branch names), but also\n+ large fixed set defined by the system that can grow over time\n+ (e.g. what kind of common whitespace problems to notice). Use\n+ subsection names or variable values, like existing variables\n+ branch..description and core.whitespace do, instead.\n+\n+\n Writing Documentation:\n \n Most (if not all) of the documentation pages are written in the\n-- \n2.3.0-rc2-149-gdd42ee9\n"},{"id":"255485","messageId":"54CDB5C6.3020702@alum.mit.edu","threadId":"38453","inReplyTo":"1422484393-4414-4-git-send-email-gitster@pobox.com","subject":"Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-02-01T05:12:38Z","receivedAt":"2015-02-01T05:12:38Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 01/28/2015 11:33 PM, Junio C Hamano wrote:\n> We may want to say something about command line option names in the\n> new section as well, but for now, let's make sure everybody is clear\n> on how to structure and name their configuration variables.\n> \n> The text for the rules are partly taken from the log message of\n> Jonathan's 6b3020a2 (add: introduce add.ignoreerrors synonym for\n> add.ignore-errors, 2010-12-01).\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> Documentation/CodingGuidelines | 25 +++++++++++++++++++++++++\n> 1 file changed, 25 insertions(+)\n> \n> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n> index 894546d..8fbac15 100644\n> --- a/Documentation/CodingGuidelines\n> +++ b/Documentation/CodingGuidelines\n> @@ -413,6 +413,31 @@ Error Messages\n> - Say what the error is first (\"cannot open %s\", not \"%s: cannot open\")\n> \n> \n> +Externally Visible Names\n> +\n> + - For configuration variable names, follow the existing convention:\n> +\n> + . The section name indicates the affected subsystem.\n> +\n> + . The subsection name, if any, indicates which of an unbounded set\n> + of things to set the value for.\n> +\n> + . The variable name describes the effect of tweaking this knob.\n> +\n> + The section and variable names that consist of multiple words are\n> + formed by concatenating the words without punctuations (e.g. `-`),\n> + and are broken using bumpyCaps in documentation as a hint to the\n> + reader.\n> +\n> + When choosing the variable namespace, do not use variable name for\n> + specifying possibly unbounded set of things, most notably anything\n> + an end user can freely come up with (e.g. branch names), but also\n> + large fixed set defined by the system that can grow over time\n> + (e.g. what kind of common whitespace problems to notice).\n\nI think we can all agree with this rule for \"anything an end user can\nfreely come up with\". Such sets are truly unbounded.\n\nBut what is the justification for applying it to \"large fixed set\ndefined by the system that can grow over time\"? Any set of items that\nneeds to be programmed one by one is not unbounded in the same sense. It\nis true that it can grow over time, but there is a practical limit on\nhow many such options we would ever implement, and at any given time the\nset has a well-defined, finite number of members.\n\nI suppose that this is a reaction to Johannes's proposal [1] to add\nconfiguration settings like\n\n git config fsck.badDate ignore\n\n[2] which you didn't like [3] but I did [4]. (Did you miss [4], in which\nI think I made some good arguments for Johannes's proposal? I don't\nthink you responded to it.)\n\nI think it would be more productive to finish the concrete discussion\nabout the \"fsck\" proposal, and to use the insight gained in that\nspecific case to inform the decision about whether we need the new\ngeneral rule to cover \"large fixed set[s] defined by the system\".\n\n> + [...] Use\n> + subsection names or variable values, like existing variables\n> + branch..description and core.whitespace do, instead.\n\nBut there is also a precedent for the opposite approach: \"advice.*\".\n\n [advice]\n pushUpdateRejected = true|false\n pushNonFFCurrent = true|false\n statusHints = true|false\n resolveConflict = true|false\n\netc.\n\nIn fact, I would argue that\n\n [core]\n whitespace = blank-at-eol -indent-with-non-tab\n\nis a bad model to follow, and would better have been expressed in a\nstyle like\n\n [whitespace]\n blankAtEOL = warn\n indentWithNonTab = ignore\n\nfor the same reasons that I argued for \"fsck.*\". The latter style would\nalso have made it easier to add other choices like\n\"whitespace.spaceBeforeTab = error\". Not that I am advocating that\nparticular enhancement; I am just giving an example of how the current\nstyle of configuration is less flexible.\n\n> [...]\n\nMichael\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/261068\n[2] Actually, the original proposal was for \"fsck.bad-date\", but I think\nwe agree that \"fsck.badDate\" would be the correct version of this proposal.\n[3] http://article.gmane.org/gmane.comp.version-control.git/261738\n[4] http://article.gmane.org/gmane.comp.version-control.git/262841\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"255488","messageId":"20150201164435.GA17853@peff.net","threadId":"38453","inReplyTo":"54CDB5C6.3020702@alum.mit.edu","subject":"Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-01T16:44:36Z","receivedAt":"2015-02-01T16:44:36Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 01, 2015 at 06:12:38AM +0100, Michael Haggerty wrote:\n\n> > + When choosing the variable namespace, do not use variable name for\n> > + specifying possibly unbounded set of things, most notably anything\n> > + an end user can freely come up with (e.g. branch names), but also\n> > + large fixed set defined by the system that can grow over time\n> > + (e.g. what kind of common whitespace problems to notice).\n> \n> I think we can all agree with this rule for \"anything an end user can\n> freely come up with\". Such sets are truly unbounded.\n> \n> But what is the justification for applying it to \"large fixed set\n> defined by the system that can grow over time\"? Any set of items that\n> needs to be programmed one by one is not unbounded in the same sense. It\n> is true that it can grow over time, but there is a practical limit on\n> how many such options we would ever implement, and at any given time the\n> set has a well-defined, finite number of members.\n\nI had the same reaction on reading this.\n\nWe should be striving to break config options down as much as possible\nto single scalar values, because that is the only format that is\nunderstood systematically by the config code.\n\nIf a config option's value is a list, then we have to come up with an\nad-hoc syntax for the list, which we parse in the config callback. And\nthat leaves users of \"git config\" to reinvent that parsing themselves\nwhen they want to do simple things like \"remove item B from the list\".\nI think the examples you gave over on the fsck thread all make the same\npoint.\n\n> > + [...] Use\n> > + subsection names or variable values, like existing variables\n> > + branch..description and core.whitespace do, instead.\n> \n> But there is also a precedent for the opposite approach: \"advice.*\".\n\nThe pager.*, color.* (and color.$program.*) examples come to mind. For\nexample, we did not add:\n\n [core]\n usePagerFor = log, diff, -status\n\nbut instead:\n\n [pager]\n log = true\n diff = true\n status = false\n\nNot only is the latter easier to manipulate and examine with the\nexisting config tools, I think it is more flexible in the long run. We\nlater extended the syntax to allow:\n\n [pager]\n log = diff-highlight | less\n\nwhich would have been even more awkward in the \"userPagerFor\" format\n(you could use \"log=...\", of course, but now you need to get into\nwhitespace quoting and other complexities, all of which are handled\nalready by the config code in the latter case).\n\n-Peff\n"},{"id":"255491","messageId":"xmqq1tm99yhx.fsf@gitster.dls.corp.google.com","threadId":"38453","inReplyTo":"54CDB5C6.3020702@alum.mit.edu","subject":"Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-01T20:18:34Z","receivedAt":"2015-02-01T20:18:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> On 01/28/2015 11:33 PM, Junio C Hamano wrote:\n>> + When choosing the variable namespace, do not use variable name for\n>> + specifying possibly unbounded set of things, most notably anything\n>> + an end user can freely come up with (e.g. branch names), but also\n>> + large fixed set defined by the system that can grow over time\n>> + (e.g. what kind of common whitespace problems to notice).\n>\n> I think we can all agree with this rule for \"anything an end user can\n> freely come up with\". Such sets are truly unbounded.\n>\n> But what is the justification for applying it to \"large fixed set\n> defined by the system that can grow over time\"? Any set of items that\n> needs to be programmed one by one is not unbounded in the same sense. It\n> is true that it can grow over time, but there is a practical limit on\n> how many such options we would ever implement, and at any given time the\n> set has a well-defined, finite number of members.\n>\n> I suppose that this is a reaction to Johannes's proposal [1] to add\n> configuration settings like\n>\n> git config fsck.badDate ignore\n\nNot really.\n\nThis started after I looked at the add.ignore-errors issue discussed\nand I was trying to codify existing practices by running greps,\nblames and logs on 'master' to see what potential pitfalls are, and\nwhat good existing practices to follow suit we already had.\n\nThe fsck changes were not in my mind at all.\n\nI can see it argued that for things that are completely independent\n(e.g. the consequence of setting fsck.badDate can never be affected\nby how fsck.missingTagger is configured), separate configuration\nvariables may not be wrong per-se, but I can see that a set of knobs\nthat would have been originally independent, as the operation grow\nricher, gain more semantics to make them related, and at that point,\nI doubt \"they are internally independent; expose them as independent\nto the end users\" argument would hold water that well.\n\nA good example is \"core.whitespace\", where you would have started\nwith a simple set of booleans (\"blank-at-eol\" and \"space-before-tab\"\nare conceptually independent and will stay to be), but once you\nstart supporting \"indent-with-non-tab\" and \"tab-in-indent\" you\ncannot pretend that they are independent.\n\nAnd that is the \"existing practice\" I primarily had in mind. We\ndidn't do\n\n\twhitespace.tabInIndent = true\n whitespace.indentWithNonTab = true\n\nto pretend they are independent and still internally having to make\nsure the consistency of the setting. We structured the syntax for\nease of the end user (not scripter) to shorter\n\n\tcore.whitespace = tab-in-indent,indent-with-non-tab\n\nas we need the consistency thing either way (and it is easier to see\nthe consistency mistakes when they appear next to each other).\n\nAnd I am happy that we chose wisely in an early version that didn't\nuse one-variable-per-knob but used list-of-features-as-value instead.\n\n\n> [2] which you didn't like [3] but I did [4]. (Did you miss [4], in which\n> I think I made some good arguments for Johannes's proposal? I don't\n> think you responded to it.)\n\nI saw it, found it as an argument between \"not good\" and \"weak\" (see\nabove), kept in my mailbox while trying to decide if it was worth\nresponding, and then forgot about it after I got busy dealing with\nother topics that have more relevance to the upcoming release ;-)\n\n> I think it would be more productive to finish the concrete discussion\n> about the \"fsck\" proposal,...\n\nSurely.\n\n (0) fsck.bad-date is out.\n\n (1) fsck.badDate is OK. I expect there is very high chance for\n them to stay independent forever.\n\n (2) fsck.ignore = bad-date,... is still my preference, only if it\n aligns with existing core.whitespace precedence that allows\n users to leverage the familiarity.\n\n\nI see Peff cites \"pager.\", but I think it was something that we\nwould rather shouldn't have done, similar to \"alias.\". They\nare bad precedents we shouldn't encourage new things to mimic.\n\nBut that is not from \"one-variable-with-list-is-better\" (it is not\nbetter for these \"independent\" ones) but is purely from the syntax\npoint of view. There is no good reason to force case insensitivity\nto the command names used as the key in these cases, but we do\nbecause we made them the last-level variable names, and we have to\navoid hyphens in the command names while at it if we want to be\nconsistent (and the consistency was the point of the original\nadd.ignore-errors discussion that started all this, after all).\n\nIf they were\n\n pager.diff.enable = true\n alias.co.command = checkout\n\nthe world would have been a lot better place.\n"},{"id":"255494","messageId":"20150201215729.GA19692@peff.net","threadId":"38453","inReplyTo":"xmqq1tm99yhx.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-01T21:57:30Z","receivedAt":"2015-02-01T21:57:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 01, 2015 at 12:18:34PM -0800, Junio C Hamano wrote:\n\n> I can see it argued that for things that are completely independent\n> (e.g. the consequence of setting fsck.badDate can never be affected\n> by how fsck.missingTagger is configured), separate configuration\n> variables may not be wrong per-se, but I can see that a set of knobs\n> that would have been originally independent, as the operation grow\n> richer, gain more semantics to make them related, and at that point,\n> I doubt \"they are internally independent; expose them as independent\n> to the end users\" argument would hold water that well.\n\nI'm not sure I buy this argument. There are two syntaxes being discussed\nhere. Let's look at each.\n\nLet's call this \"type 1\":\n\n [core]\n foo = bar -moof xyzzy=whatever\n\nWe have a single variable, but the value of that variable is essentially\na list of sub-variables. The sub-variables are either booleans (like\n\"bar\" or \"-moof\") or possibly have values of their own (with an \"=\").\nThe sub-variables are tied together logically by being part of a single\n\"core.foo\". Presumably the user can infer some relationship between them\nthrough this.\n\nType 2 is more like:\n\n [foo]\n bar = true\n moof = false\n xyzzy = whatever\n\nSo we still have our same set of sub-variables, except now each is a\nfirst-class config variable. They are tied together logically by being\npart of a single section (I called it \"foo\" here, which drops the\n\"core\"; but clearly we could give it whatever descriptive name we\nwanted).\n\n>From the user's perspective, I don't see how the implied relationships\nare significantly different. In type 1, they are placed inside a single\nvalue and in type 2, they are not. Both are a form of grouping.\n\nMoreover, I am not even sure that the syntax is an important element in\ncommunicating semantic relationships. In these examples, are \"bar\" and\n\"moof\" dependent? Clearly they are _related_ by our grouping. But does\none depend on the other? Similarly, with the existing core.whitespace,\nwhat tells you which of the sub-variables are related. The\n\"blank-at-eol\" and \"space-before-tab\" variables are both\nwhitespace-related, but do not depend on each other at all. But\n\"indent-with-non-tab\" and \"tab-in-indent\" are. Yet those two pairs are\nrepresented the same way syntactically.\n\nI don't think you can infer semantic independence from syntax. It's\nsimply too blunt an instrument (and as you noted, it may even change\nover time).\n\n> We structured the syntax for ease of the end user (not scripter) to\n> shorter\n> \n> \tcore.whitespace = tab-in-indent,indent-with-non-tab\n> \n> as we need the consistency thing either way (and it is easier to see\n> the consistency mistakes when they appear next to each other).\n\nI agree that this provides a slight advantage to \"type 1\", because it\nrequires syntactically that the definitions are near each other (whereas\nwith split variables, they can literally be in different files). And if\neverything else were equal, that would be enough. But I think \"type 1\"\nhas a lot of other disadvantages. For example:\n\n 1. I'm a user who has set my preferred core.whitespace in my\n ~/.gitconfig. A particular project I am working on uses an\n alternate tabwidth. How do I set that in the repo config without\n repeating my defaults?\n\n 2. I'm writing a hook whose behavior depends on the whitespace\n settings. How do I ask git whether blank-at-eol is enabled?\n\n 3. I'm a user who wants to set whitespace config. I prefer using \"git\n config\" to editing the file manually. How do I turn off\n blank-at-eol without disrupting my existing settings?\n\nAn astute reader will notice that case (1) is a double-edged sword. If\nyour defaults have \"blank-at-eol\" and you want to set\n\"indent-with-non-tab\" in the repo, that's fine. If the default is\n\"tab-in-indent\" and you want to set \"indent-with-non-tab\", then those\nare in conflict (i.e., this is the exact thing you were complaining\nabout above).\n\nBut is it such a bad thing to have them in conflict? Can't we define a\nset of rules that does what people expects? For example, by the \"last\none wins\" principle, any time we see \"whitespace.tab-in-indent\", it\nclears the setting of \"whitespace.indent-with-non-tab\", and vice versa.\nThis isn't represented syntactically in the config file, but it is an\neasy rule, does what people would want, and can be documented in\nconfig.txt (which is where we have to talk about such semantic conflicts\nanyway).\n\nBy the way, this is the exact case I am concerned about for fsck.*. Our\nuse case at GitHub would be something like:\n\n a. We set up sane defaults for fsck.* in /etc/gitconfig\n\n b. User complains that we will not accept their push, which contains\n objects with malformed committers.\n\n c. Support investigates, determines that the malformed objects are\n part of a well-established history, and that they are OK to enter.\n\n d. We relax fsck.committerIdent in that repo's $GIT_DIR/config file.\n\nCopy-and-pasting the rest of the rules from (a) into the repo config\nfile in step (d) is not ideal.\n\n> I see Peff cites \"pager.\", but I think it was something that we\n> would rather shouldn't have done, similar to \"alias.\". They\n> are bad precedents we shouldn't encourage new things to mimic.\n> \n> But that is not from \"one-variable-with-list-is-better\" (it is not\n> better for these \"independent\" ones) but is purely from the syntax\n> point of view.\n\nYeah, I'd agree that the problem there is orthogonal to the type 1/2\nthing above. I don't think it has been a big deal in practice, just\nbecause people with good taste do not name their commands with uppercase\nanyway.\n\nI'd be happy to transition to pager.*.enabled, etc, if we care. That is\na much more flexible system anyway, and I do not think there is any\nbackwards compatibility problem (we'd continue with alias.X as a synonym\nfor alias.X.command indefinitely). It would not even be that much work;\nit is mostly that I have never seen anybody complain about it in the\nreal world.\n\n-Peff\n"},{"id":"255495","messageId":"xmqqwq418dmp.fsf@gitster.dls.corp.google.com","threadId":"38453","inReplyTo":"20150201215729.GA19692@peff.net","subject":"Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-01T22:34:38Z","receivedAt":"2015-02-01T22:34:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> From the user's perspective, I don't see how the implied relationships\n> are significantly different. In type 1, they are placed inside a single\n> value and in type 2, they are not. Both are a form of grouping.\n>\n> Moreover, I am not even sure that the syntax is an important element in\n> communicating semantic relationships.\n\nI think we are in agreement and I do not see how you can draw\ndifferent conclusions. The above argument refutes the point Michael\nmade a big deal out of, which was that \"these are individual and\nindependent bools in the implementation detail of the code, expose\nthat as such to the end users.\" I do not buy that point, i.e. it is\nnot a good argument to favor style 2 over style 1, which was the\nprimary thing I wanted to illustrate in the message you are\nresponding to.\n\n> 1. I'm a user who has set my preferred core.whitespace in my\n> ~/.gitconfig. A particular project I am working on uses an\n> alternate tabwidth. How do I set that in the repo config without\n> repeating my defaults?\n\nIsn't it cumulative? At least it should be (but I wouldn't be too\nsurprised if the recent config reader caching broke it).\n\n> 2. I'm writing a hook whose behavior depends on the whitespace\n> settings. How do I ask git whether blank-at-eol is enabled?\n\nIf that becomes an issue, \"git config\" would have to learn about\nthem, just like it knows about how to do --color depending on the\ntty-ness of the output.\n\n> 3. I'm a user who wants to set whitespace config. I prefer using \"git\n> config\" to editing the file manually. How do I turn off\n> blank-at-eol without disrupting my existing settings?\n\nSee above 1.\n\n>> I see Peff cites \"pager.\", but I think it was something that we\n>> would rather shouldn't have done, similar to \"alias.\". They\n>> are bad precedents we shouldn't encourage new things to mimic.\n>> \n>> But that is not from \"one-variable-with-list-is-better\" (it is not\n>> better for these \"independent\" ones) but is purely from the syntax\n>> point of view.\n>\n> Yeah, I'd agree that the problem there is orthogonal to the type 1/2\n> thing above. I don't think it has been a big deal in practice, just\n> because people with good taste do not name their commands with uppercase\n> anyway.\n>\n> I'd be happy to transition to pager.*.enabled, etc, if we care.\n\nI have no strong opinion. It was primarily meant to illustrate why\npager. and alias. were bad precedents that should not be\nused to support design of future things.\n"},{"id":"255505","messageId":"54CF1D7F.6050903@alum.mit.edu","threadId":"38453","inReplyTo":"xmqq1tm99yhx.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-02-02T06:47:27Z","receivedAt":"2015-02-02T06:47:27Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Junio,\n\nThanks for your thoughtful response.\n\nOn 02/01/2015 09:18 PM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n> \n>> On 01/28/2015 11:33 PM, Junio C Hamano wrote:\n>>> + When choosing the variable namespace, do not use variable name for\n>>> + specifying possibly unbounded set of things, most notably anything\n>>> + an end user can freely come up with (e.g. branch names), but also\n>>> + large fixed set defined by the system that can grow over time\n>>> + (e.g. what kind of common whitespace problems to notice).\n>>\n>> I think we can all agree with this rule for \"anything an end user can\n>> freely come up with\". Such sets are truly unbounded.\n>>\n>> But what is the justification for applying it to \"large fixed set\n>> defined by the system that can grow over time\"?\n> [...]\n> \n> I can see it argued that for things that are completely independent\n> (e.g. the consequence of setting fsck.badDate can never be affected\n> by how fsck.missingTagger is configured), separate configuration\n> variables may not be wrong per-se, but I can see that a set of knobs\n> that would have been originally independent, as the operation grow\n> richer, gain more semantics to make them related, and at that point,\n> I doubt \"they are internally independent; expose them as independent\n> to the end users\" argument would hold water that well.\n> \n> A good example is \"core.whitespace\", where you would have started\n> with a simple set of booleans (\"blank-at-eol\" and \"space-before-tab\"\n> are conceptually independent and will stay to be), but once you\n> start supporting \"indent-with-non-tab\" and \"tab-in-indent\" you\n> cannot pretend that they are independent.\n> \n> And that is the \"existing practice\" I primarily had in mind. We\n> didn't do\n> \n> \twhitespace.tabInIndent = true\n> whitespace.indentWithNonTab = true\n> \n> to pretend they are independent and still internally having to make\n> sure the consistency of the setting. We structured the syntax for\n> ease of the end user (not scripter) to shorter\n> \n> \tcore.whitespace = tab-in-indent,indent-with-non-tab\n> \n> as we need the consistency thing either way (and it is easier to see\n> the consistency mistakes when they appear next to each other).\n> \n> And I am happy that we chose wisely in an early version that didn't\n> use one-variable-per-knob but used list-of-features-as-value instead.\n\nYou make an interesting point: values that start as a list of\nindependent booleans can grow dependencies over time.\n\nIn retrospect, ISTM that a better interface for the indentation-related\n\"whitespace\" settings would have been something like\n\n* \"whitespace.indent\" -- a single value chosen from \"tabs-only |\nspaces-only | tabs-when-possible | anything\"\n* \"whitespace.tabwidth\" -- an integer value\n\nThis would have made the mutual-exclusivity of those choices manifest in\nthe style of configuration rather than hoping that the user notices that\nhis settings contradict each other.\n\nLet's dig into this example some more by imagining some other\nhypothetical future extensions. Suppose we wanted to support different\nwhitespace rules for different types of files [1]. For example, I might\nnever want to forbid \"cr-at-eol\" everywhere, and might usually like to\nuses spaces for my indentation, but for Makefiles need to indent using\ntabs. The \"type 2\" syntax, I think, is pretty straightforward:\n\n [whitespace]\n cr-at-eol = error\n indent = spaces-only\n\n [whitespace \"makefile\"]\n indent = tabs-only\n\nOur usual rules, \"last setting wins\" and \"foo.*.bar, if present, takes\nprecedence overrides foo.bar\", make it pretty clear how the above should\nbe interpreted.\n\nWhat would be the \"type 1\" syntax for this? Would \"cr-at-eol\" be\ninherited from \"core.whitespace\" to \"core.makefile.whitespace\"? If not,\nthen I have to repeat \"cr-at-eol\":\n\n [core]\n whitespace = cr-at-eol tab-in-indent\n [core \"makefile\"]\n whitespace = cr-at-eol indent-with-non-tab\n\n[2]. If values are inherited, then do I also have to countermand\n\"tab-in-indent\" in the \"makefile\" rule?\n\n [core]\n whitespace = cr-at-eol tab-in-indent\n [core \"makefile\"]\n whitespace = indent-with-non-tab -tab-in-indent\n\nOr does \"indent-with-non-tab\" automatically supersede \"tab-in-indent\",\naccording to last-setting-wins (an interpretation that starts requiring\nthe config parser to have domain-specific knowledge)?:\n\n [core]\n whitespace = cr-at-eol tab-in-indent\n [core \"makefile\"]\n whitespace = indent-with-non-tab\n\nBut if that is the case, which setting wins in this scenario?:\n\n [core]\n whitespace = cr-at-eol tab-in-indent\n [core \"makefile\"]\n whitespace = indent-with-non-tab\n # In another config file maybe:\n [core]\n whitespace = space-before-tab\n\nDoes \"core.whitespace = space-before-tab\" supersede\n\"core.makefile.whitespace = indent-with-non-tab\" here?\n\nNo matter which of the \"type 1\" variants we choose, we would have to\ninvent new rules for users and config parsers to learn, and some of\nthose rules would require domain-specific knowledge to interpret.\nWhereas the \"type 2\" style is pretty straightforward and leans only on\nexisting conventions.\n\n> [...]\n\nMichael\n\n[1] I'm not claiming that this specific extension makes sense. It might\nmake more sense to configure the whitespace rules one-by-one using\ngitattributes. But I think it is nevertheless a typical way that\nfeatures are extended and therefore an interesting gedankenexperiment.\n\n[2] For the purposes of this discussion, let's ignore the fact that\nthere is no precedent for a three-level \"core\" setting like\n\"core.makefile.whitespace\". It could just as easily be spelled\n\"whitespace.makefile.check\" or something in the \"type 1\" syntax.\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"255509","messageId":"687227472e6697fadfa9c3237c9c7de0@www.dscho.org","threadId":"38453","inReplyTo":"xmqqwq418dmp.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-02-02T11:31:26Z","receivedAt":"2015-02-02T11:31:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn 2015-02-01 23:34, Junio C Hamano wrote:\n> Jeff King writes:\n> \n>> 1. I'm a user who has set my preferred core.whitespace in my\n>> ~/.gitconfig. A particular project I am working on uses an\n>> alternate tabwidth. How do I set that in the repo config without\n>> repeating my defaults?\n> \n> Isn't it cumulative? At least it should be (but I wouldn't be too\n> surprised if the recent config reader caching broke it).\n\nPlease note that it is really, really difficult for a regular Git user to figure out which whitespace settings are in effect using just `git config` whether it is cumulative or not.\n\nAlso, please note it makes it hard on users that there are a bunch of config settings which *override* previous settings, and others that are *cumulative*.\n\nThe latter we cannot change, and the former we cannot change for the whitespace settings. However, when introducing new settings (such as the fsck severity levels), we should go out of our way to keep things as simple as possible. For example, if a *simple* `git config` can answer the question \"Is feature XYZ turned on\", I would consider the design superior to a design that requires additional code just to figure out whether feature XYZ is turned on, let alone to turn it on without affecting other settings.\n\nIn other words, I would like to caution against recommending the whitespace setting as an example to follow: anybody who is unfamiliar with the whitespace setting will find the cumulative last-setting-wins (per item inside the whitespace-separated list, not per config setting) strategy confusing.\n\nOn the other hand, if you offer `whitespace.tabWidth` and `whitespace.indentWithNoTab` separately, everything is really crystal clear to new users without having much explaining to do, let alone having to introduce new tooling.\n\nCiao,\nDscho\n\nP.S.: Of course I know that it is too late for `whitespace`, but it offers itself as a good subject to demonstrate the merits of the different suggestions.\n"},{"id":"255524","messageId":"xmqq7fw0uphd.fsf@gitster.dls.corp.google.com","threadId":"38453","inReplyTo":"20150201215729.GA19692@peff.net","subject":"Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-02T18:39:58Z","receivedAt":"2015-02-02T18:39:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\nI didn't reply to the latter part of this message yesterday, because\nI wanted to think more on it.\n\n> But is it such a bad thing to have them in conflict? Can't we define a\n> set of rules that does what people expects? For example, by the \"last\n> one wins\" principle, any time we see \"whitespace.tab-in-indent\", it\n> clears the setting of \"whitespace.indent-with-non-tab\", and vice versa.\n> This isn't represented syntactically in the config file, ...\n\nI agree. Both one-variable-per-knob and value-with-list-of-knobs do\nnot express the semantic linkage between knobs; once we convince the\nusers that one-variable-per-knob format does not mean they represent\nindependent and orthgonal settings, the issue becomes a trade-off\nbetween\n\n * Is it concise to let end users skim through?\n * Is it easy to parse by scripters?\n\n> By the way, this is the exact case I am concerned about for fsck.*. Our\n> use case at GitHub would be something like:\n>\n> a. We set up sane defaults for fsck.* in /etc/gitconfig\n>\n> b. User complains that we will not accept their push, which contains\n> objects with malformed committers.\n>\n> c. Support investigates, determines that the malformed objects are\n> part of a well-established history, and that they are OK to enter.\n>\n> d. We relax fsck.committerIdent in that repo's $GIT_DIR/config file.\n>\n> Copy-and-pasting the rest of the rules from (a) into the repo config\n> file in step (d) is not ideal.\n\nIt probably can be worked around by the later-one-wins rule per\nitem, e.g. after seeing \"fsck.ignore = A B C\" in /etc/gitconfig and\nthen seeing \"fsck.error = B\" in $GIT_DIR/config, the latter will\nflip the three-way radio button for B from ignore to error (the\nother possible setting of the radio button is 'warn'), while leaving\nthe three-way radio buttons for A and C set to ignore.\n\nWe can (and have to) do the same with \"fsck.B = ignore\" in\n/etc/gitconfig that gets overridden by \"fsck.B = error\" in\n$GIT_DIR/config, and that comes _free_, which makes it an\nattractive proposition.\n\nAs I already said, I am fine with \"fsck.missingTagger = ignore\".\n"},{"id":"255530","messageId":"xmqq386ouotd.fsf@gitster.dls.corp.google.com","threadId":"38453","inReplyTo":"54CF1D7F.6050903@alum.mit.edu","subject":"Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-02T18:54:22Z","receivedAt":"2015-02-02T18:54:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> You make an interesting point: values that start as a list of\n> independent booleans can grow dependencies over time.\n>\n> In retrospect, ISTM that a better interface for the indentation-related\n> \"whitespace\" settings would have been something like\n>\n> * \"whitespace.indent\" -- a single value chosen from \"tabs-only |\n> spaces-only | tabs-when-possible | anything\"\n> * \"whitespace.tabwidth\" -- an integer value\n>\n> This would have made the mutual-exclusivity of those choices manifest in\n> the style of configuration rather than hoping that the user notices that\n> his settings contradict each other.\n>\n> Let's dig into this example some more by imagining some other\n> hypothetical future extensions.\n\nLet's not; that line of thought entirely misses the point. If you\nstart from one set of variables, you can define a structure\n(e.g. \"there are indentation-related and you must choose only one\namong them\") over it after the fact.\n\nOnce you have chosen a structure, you have to live with it. Either\nyou make sure that a structure itself is extensible, or you make\nsure you accept a new variable only if it fits within a structure.\nEither way, you lose. You cannot predict the future, and you do not\nwant to constrain those who will contribute to the project in the\nfuture.\n\nMy aversion to one-variable-per-knob was primarily against the\n\"because that is how the variables are internally represented; a\ncollection of enums that can be independently set\" argument. If we\nassume that one-variable-per-knob style implies variables that can\nbe independently set, that _is_ defining the structure the future\nwork has to live within.\n\nBut as I and Peff discussed in the other sub(sub)thread, having two\nvariables placed flatly in the namespace, e.g. ws.indentWithTab and\nws.noTabInIndent, does not have to mean they are independent.\n\nAnd the opposite is also true; having these two knobs as possible\nelements of the value of a single variable does not imply they\nalways have meaningful interactions.\n\nSo I am fine with \"fsck.missingTagger = ignore/warn/error\", as long\nas the argument that supports the style is not \"because\nfsck.missingTagger and fsck.malformedIdent are independent\".\n"}]}