// Package config implements encoding and decoding of git config files. // // Configuration File // ------------------ // // The Git configuration file contains a number of variables that affect // the Git commands' behavior. The `.git/config` file in each repository // is used to store the configuration for that repository, and // `$HOME/.gitconfig` is used to store a per-user configuration as // fallback values for the `.git/config` file. The file `/etc/gitconfig` // can be used to store a system-wide default configuration. // // The configuration variables are used by both the Git plumbing // and the porcelains. The variables are divided into sections, wherein // the fully qualified variable name of the variable itself is the last // dot-separated segment and the section name is everything before the last // dot. The variable names are case-insensitive, allow only alphanumeric // characters and `-`, and must start with an alphabetic character. Some // variables may appear multiple times; we say then that the variable is // multivalued. // // Syntax // ~~~~~~ // // The syntax is fairly flexible and permissive; whitespaces are mostly // ignored. The '#' and ';' characters begin comments to the end of line, // blank lines are ignored. // // The file consists of sections and variables. A section begins with // the name of the section in square brackets and continues until the next // section begins. Section names are case-insensitive. Only alphanumeric // characters, `-` and `.` are allowed in section names. Each variable // must belong to some section, which means that there must be a section // header before the first setting of a variable. // // Sections can be further divided into subsections. To begin a subsection // put its name in double quotes, separated by space from the section name, // in the section header, like in the example below: // // -------- // [section "subsection"] // // -------- // // Subsection names are case sensitive and can contain any characters except // newline (doublequote `"` and backslash can be included by escaping them // as `\"` and `\\`, respectively). Section headers cannot span multiple // lines. Variables may belong directly to a section or to a given subsection. // You can have `[section]` if you have `[section "subsection"]`, but you // don't need to. // // There is also a deprecated `[section.subsection]` syntax. With this // syntax, the subsection name is converted to lower-case and is also // compared case sensitively. These subsection names follow the same // restrictions as section names. // // All the other lines (and the remainder of the line after the section // header) are recognized as setting variables, in the form // 'name = value' (or just 'name', which is a short-hand to say that // the variable is the boolean "true"). // The variable names are case-insensitive, allow only alphanumeric characters // and `-`, and must start with an alphabetic character. // // 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. // // 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). Other char escape sequences (including octal // escape sequences) are invalid. // // Includes // ~~~~~~~~ // // You can include one config file from another by setting the special // `include.path` variable to the name of the file to be included. The // variable takes a pathname as its value, and is subject to tilde // expansion. // // The included file is expanded immediately, as if its contents had been // found at the location of the include directive. If the value of the // `include.path` variable is a relative path, the path is considered to be // relative to the configuration file in which the include directive was // found. See below for examples. // // // Example // ~~~~~~~ // // # Core variables // [core] // ; Don't trust file modes // filemode = false // // # Our diff algorithm // [diff] // external = /usr/local/bin/diff-wrapper // renames = true // // [branch "devel"] // remote = origin // merge = refs/heads/devel // // # Proxy settings // [core] // gitProxy="ssh" for "kernel.org" // gitProxy=default-proxy ; for the rest // // [include] // path = /path/to/foo.inc ; include by absolute path // path = foo ; expand "foo" relative to the current file // path = ~/foo ; expand "foo" in your `$HOME` directory // package config