git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v2 3/7] Documentation/config.txt: describe the structure first and then meaning

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 4, 2015, 21:33 UTC
Message-ID
<1425504803-16039-4-git-send-email-gitster@pobox.com>
In-Reply-To
<1425504803-16039-1-git-send-email-gitster@pobox.com>

A line can be continued via a backquote-LF and can be chomped at a comment character. But that is not specific to string-typed values. It is common to all, just like unquoted leading and trailing whitespaces are stripped and inter-word spacing are retained.

Move the description around and desribe these structural rules first, then introduce the double-quote facility as a way to override them, and finally mention various types of values.

Note that these structural rules only apply to the value part of the configuration file. E.g.

    [aSection] \
        name \
	= value

does not work, because the rules kick in only after seeing "name =". Both the original and the updated text are phrased in an awkward way by singling out the "value" part of the line because of this.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config.txt | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 405bf25..1444614 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -59,32 +59,31 @@ is taken as 'name' and the variable is recognized as boolean "true".
 The variable names are case-insensitive, allow only alphanumeric characters
 and `-`, and must start with an alphabetic character.
 
-Leading and trailing whitespace in a variable value is discarded.
-Internal whitespace within a variable value is retained verbatim.
+A line that defines a value can be continued to the next line by
+ending it with a `\`; the backquote and the end-of-line are
+stripped.  Leading whitespaces after 'name =', the remainder of the
+line after the first comment character '#' or ';', and trailing
+whitespaces of the line are discarded unless they are enclosed in
+double quotes.  Internal whitespaces within the value are retained
+verbatim.
 
-The values following the equals sign in variable assign are all either
-a string, an integer, or a boolean.  Boolean values may be given as yes/no,
-1/0, true/false or on/off.  Case is not significant in boolean values, when
-converting value to the canonical form using '--bool' type specifier;
-'git config' will ensure that the output is "true" or "false".
-
-String values may be entirely or partially enclosed in double quotes.
-You need to enclose variable values in double quotes if you want to
-preserve leading or trailing whitespace, or if the variable value contains
-comment characters (i.e. it contains '#' or ';').
-Double quote `"` and backslash `\` characters in variable values must
-be escaped: use `\"` for `"` and `\\` for `\`.
+Inside double quotes, double quote `"` and backslash `\` characters
+must be escaped: use `\"` for `"` and `\\` for `\`.
 
 The following escape sequences (beside `\"` and `\\`) are recognized:
 `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
 and `\b` for backspace (BS).  No other char escape sequence, nor octal
 char sequences are valid.
 
-Variable values ending in a `\` are continued on the next line in the
-customary UNIX fashion.
+The values following the equals sign in variable assign are all either
+a string, an integer, or a boolean.  Boolean values may be given as yes/no,
+1/0, true/false or on/off.  Case is not significant in boolean values, when
+converting value to the canonical form using '--bool' type specifier;
+'git config' will ensure that the output is "true" or "false".
 
 Some variables may require a special value format.
 
+
 Includes
 ~~~~~~~~
 
-- 
2.3.1-316-g7c93423
Previous: Junio C HamanoNext: Junio C Hamano
Message 12 of 16 in “[Q] should "color.*.<slot> = normal" emit nothing?”
  1. Junio C HamanoFeb 18, 2015
  2. log --decorate: do not leak "commit" color into the next itemJunio C Hamano, Feb 18, 2015
  3. Jeff KingFeb 18, 2015
  4. Junio C HamanoFeb 19, 2015
  5. Jeff KingFeb 20, 2015
  6. Junio C HamanoFeb 20, 2015
  7. Jeff KingFeb 21, 2015
  8. Junio C HamanoFeb 21, 2015
  9. 0/7 Fix leak of color/attributes in "git log --decorate"Junio C Hamano, Mar 4, 2015
  10. 1/7 Documentation/config.txt: avoid unnecessary negationJunio C Hamano, Mar 4, 2015
  11. 2/7 Documentation/config.txt: explain multi-valued variables onceJunio C Hamano, Mar 4, 2015
  12. 3/7 Documentation/config.txt: describe the structure first and then meaningJunio C Hamano, Mar 4, 2015
  13. 4/7 Documentation/config.txt: have a separate "Values" sectionJunio C Hamano, Mar 4, 2015
  14. 5/7 Documentation/config.txt: describe 'color' value type in the "Values" sectionJunio C Hamano, Mar 4, 2015
  15. 6/7 Documentation/config.txt: simplify boolean description in the syntax sectionJunio C Hamano, Mar 4, 2015
  16. 7/7 log --decorate: do not leak "commit" color into the next itemJunio C Hamano, Mar 4, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.