{"thread":{"id":"25878","subject":"[PATCH] Documentation/config.txt: Order variables alphabetically","startedAt":"2010-12-01T13:12:54Z","lastAt":"2010-12-02T09:32:58Z","messageCount":17,"participants":["jari.aalto@cante.net","Jakub Narebski","jari","Erik Faye-Lund","Jari Aalto","Jeff King","SZEDER Gábor"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"156922","messageId":"1291209174-9239-1-git-send-email-jari.aalto@cante.net","threadId":"25878","inReplyTo":null,"subject":"[PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T13:12:54Z","receivedAt":"2010-12-01T13:12:54Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"From: Jari Aalto <jari.aalto@cante.net>\n\n\nSigned-off-by: Jari Aalto <jari.aalto@cante.net>\n---\n Documentation/config.txt | 1698 +++++++++++++++++++++++-----------------------\n 1 files changed, 852 insertions(+), 846 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 6a6c0b5..6e92623 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -142,313 +142,251 @@ advice.*::\n \tdetachedHead::\n \t\tAdvice shown when you used linkgit::git-checkout[1] to\n \t\tmove to the detach HEAD state, to instruct how to create\n-\t\ta local branch after the fact.  Default: true.\n+\t\ta local branch after the fact.\tDefault: true.\n --\n \n-core.fileMode::\n-\tIf false, the executable bit differences between the index and\n-\tthe working copy are ignored; useful on broken filesystems like FAT.\n-\tSee linkgit:git-update-index[1].\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].\n+\n+alias.*::\n+\tCommand aliases for the linkgit:git[1] command wrapper - e.g.\n+\tafter defining \"alias.last = cat-file commit HEAD\", the invocation\n+\t\"git last\" is equivalent to \"git cat-file commit HEAD\". To avoid\n+\tconfusion and troubles with script usage, aliases that\n+\thide existing git commands are ignored. Arguments are split by\n+\tspaces, the usual shell quoting and escaping is supported.\n+\tquote pair and a backslash can be used to quote them.\n +\n-The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]\n-will probe and set core.fileMode false if appropriate when the\n-repository is created.\n+If the alias expansion is prefixed with an exclamation point,\n+it will be treated as a shell command.\tFor example, defining\n+\"alias.new = !gitk --all --not ORIG_HEAD\", the invocation\n+\"git new\" is equivalent to running the shell command\n+\"gitk --all --not ORIG_HEAD\".  Note that shell commands will be\n+executed from the top-level directory of a repository, which may\n+not necessarily be the current directory.\n \n-core.ignoreCygwinFSTricks::\n-\tThis option is only used by Cygwin implementation of Git. If false,\n-\tthe Cygwin stat() and lstat() functions are used. This may be useful\n-\tif your repository consists of a few separate directories joined in\n-\tone hierarchy using Cygwin mount. If true, Git uses native Win32 API\n-\twhenever it is possible and falls back to Cygwin functions only to\n-\thandle symbol links. The native mode is more than twice faster than\n-\tnormal Cygwin l/stat() functions. True by default, unless core.filemode\n-\tis true, in which case ignoreCygwinFSTricks is ignored as Cygwin's\n-\tPOSIX emulation is required to support core.filemode.\n+am.keepcr::\n+\tIf true, git-am will call git-mailsplit for patches in mbox format\n+\twith parameter '--keep-cr'. In this case git-mailsplit will\n+\tnot remove `\\r` from lines ending with `\\r\\n`. Can be overridden\n+\tby giving '--no-keep-cr' from the command line.\n+\tSee linkgit:git-am[1], linkgit:git-mailsplit[1].\n \n-core.ignorecase::\n-\tIf true, this option enables various workarounds to enable\n-\tgit to work better on filesystems that are not case sensitive,\n-\tlike FAT. For example, if a directory listing finds\n-\t\"makefile\" when git expects \"Makefile\", git will assume\n-\tit is really the same file, and continue to remember it as\n-\t\"Makefile\".\n-+\n-The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]\n-will probe and set core.ignorecase true if appropriate when the repository\n-is created.\n+apply.ignorewhitespace::\n+\tWhen set to 'change', tells 'git apply' to ignore changes in\n+\twhitespace, in the same way as the '--ignore-space-change'\n+\toption.\n+\tWhen set to one of: no, none, never, false tells 'git apply' to\n+\trespect all whitespace differences.\n+\tSee linkgit:git-apply[1].\n \n-core.trustctime::\n-\tIf false, the ctime differences between the index and the\n-\tworking copy are ignored; useful when the inode change time\n-\tis regularly modified by something outside Git (file system\n-\tcrawlers and some backup systems).\n-\tSee linkgit:git-update-index[1]. True by default.\n+apply.whitespace::\n+\tTells 'git apply' how to handle whitespaces, in the same way\n+\tas the '--whitespace' option. See linkgit:git-apply[1].\n \n-core.quotepath::\n-\tThe commands that output paths (e.g. 'ls-files',\n-\t'diff'), when not given the `-z` option, will quote\n-\t\"unusual\" characters in the pathname by enclosing the\n-\tpathname in a double-quote pair and with backslashes the\n-\tsame way strings in C source code are quoted.  If this\n-\tvariable is set to false, the bytes higher than 0x80 are\n-\tnot quoted but output as verbatim.  Note that double\n-\tquote, backslash and control characters are always\n-\tquoted without `-z` regardless of the setting of this\n-\tvariable.\n+branch.<name>.merge::\n+\tDefines, together with branch.<name>.remote, the upstream branch\n+\tfor the given branch. It tells 'git fetch'/'git pull' which\n+\tbranch to merge and can also affect 'git push' (see push.default).\n+\tWhen in branch <name>, it tells 'git fetch' the default\n+\trefspec to be marked for merging in FETCH_HEAD. The value is\n+\thandled like the remote part of a refspec, and must match a\n+\tref which is fetched from the remote given by\n+\t\"branch.<name>.remote\".\n+\tThe merge information is used by 'git pull' (which at first calls\n+\t'git fetch') to lookup the default branch for merging. Without\n+\tthis option, 'git pull' defaults to merge the first refspec fetched.\n+\tSpecify multiple values to get an octopus merge.\n+\tIf you wish to setup 'git pull' so that it merges into <name> from\n+\tanother branch in the local repository, you can point\n+\tbranch.<name>.merge to the desired branch, and use the special setting\n+\t`.` (a period) for branch.<name>.remote.\n \n-core.eol::\n-\tSets the line ending type to use in the working directory for\n-\tfiles that have the `text` property set.  Alternatives are\n-\t'lf', 'crlf' and 'native', which uses the platform's native\n-\tline ending.  The default value is `native`.  See\n-\tlinkgit:gitattributes[5] for more information on end-of-line\n-\tconversion.\n+branch.<name>.mergeoptions::\n+\tSets default options for merging into branch <name>. The syntax and\n+\tsupported options are the same as those of linkgit:git-merge[1], but\n+\toption values containing whitespace characters are currently not\n+\tsupported.\n \n-core.safecrlf::\n-\tIf true, makes git check if converting `CRLF` is reversible when\n-\tend-of-line conversion is active.  Git will verify if a command\n-\tmodifies a file in the work tree either directly or indirectly.\n-\tFor example, committing a file followed by checking out the\n-\tsame file should yield the original file in the work tree.  If\n-\tthis is not the case for the current setting of\n-\t`core.autocrlf`, git will reject the file.  The variable can\n-\tbe set to \"warn\", in which case git will only warn about an\n-\tirreversible conversion but continue the operation.\n-+\n-CRLF conversion bears a slight chance of corrupting data.\n-When it is enabled, git will convert CRLF to LF during commit and LF to\n-CRLF during checkout.  A file that contains a mixture of LF and\n-CRLF before the commit cannot be recreated by git.  For text\n-files this is the right thing to do: it corrects line endings\n-such that we have only LF line endings in the repository.\n-But for binary files that are accidentally classified as text the\n-conversion can corrupt data.\n-+\n-If you recognize such corruption early you can easily fix it by\n-setting the conversion type explicitly in .gitattributes.  Right\n-after committing you still have the original file in your work\n-tree and this file is not yet corrupted.  You can explicitly tell\n-git that this file is binary and git will handle the file\n-appropriately.\n-+\n-Unfortunately, the desired effect of cleaning up text files with\n-mixed line endings and the undesired effect of corrupting binary\n-files cannot be distinguished.  In both cases CRLFs are removed\n-in an irreversible way.  For text files this is the right thing\n-to do because CRLFs are line endings, while for binary files\n-converting CRLFs corrupts data.\n-+\n-Note, this safety check does not mean that a checkout will generate a\n-file identical to the original file for a different setting of\n-`core.eol` and `core.autocrlf`, but only for the current one.  For\n-example, a text file with `LF` would be accepted with `core.eol=lf`\n-and could later be checked out with `core.eol=crlf`, in which case the\n-resulting file would contain `CRLF`, although the original file\n-contained `LF`.  However, in both work trees the line endings would be\n-consistent, that is either all `LF` or all `CRLF`, but never mixed.  A\n-file with mixed line endings would be reported by the `core.safecrlf`\n-mechanism.\n+branch.<name>.rebase::\n+\tWhen true, rebase the branch <name> on top of the fetched branch,\n+\tinstead of merging the default branch from the default remote when\n+\t\"git pull\" is run.\n+\t*NOTE*: this is a possibly dangerous operation; do *not* use\n+\tit unless you understand the implications (see linkgit:git-rebase[1]\n+\tfor details).\n \n-core.autocrlf::\n-\tSetting this variable to \"true\" is almost the same as setting\n-\tthe `text` attribute to \"auto\" on all files except that text\n-\tfiles are not guaranteed to be normalized: files that contain\n-\t`CRLF` in the repository will not be touched.  Use this\n-\tsetting if you want to have `CRLF` line endings in your\n-\tworking directory even though the repository does not have\n-\tnormalized line endings.  This variable can be set to 'input',\n-\tin which case no output conversion is performed.\n+branch.<name>.remote::\n+\tWhen in branch <name>, it tells 'git fetch' and 'git push' which\n+\tremote to fetch from/push to.  It defaults to `origin` if no remote is\n+\tconfigured. `origin` is also used if you are not on any branch.\n \n-core.symlinks::\n-\tIf false, symbolic links are checked out as small plain files that\n-\tcontain the link text. linkgit:git-update-index[1] and\n-\tlinkgit:git-add[1] will not change the recorded type to regular\n-\tfile. Useful on filesystems like FAT that do not support\n-\tsymbolic links.\n-+\n-The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]\n-will probe and set core.symlinks false if appropriate when the repository\n-is created.\n+branch.autosetupmerge::\n+\tTells 'git branch' and 'git checkout' to set up new branches\n+\tso that linkgit:git-pull[1] will appropriately merge from the\n+\tstarting point branch. Note that even if this option is not set,\n+\tthis behavior can be chosen per-branch using the `--track`\n+\tand `--no-track` options. The valid settings are: `false` -- no\n+\tautomatic setup is done; `true` -- automatic setup is done when the\n+\tstarting point is a remote-tracking branch; `always` --\n+\tautomatic setup is done when the starting point is either a\n+\tlocal branch or remote-tracking\n+\tbranch. This option defaults to true.\n \n-core.gitProxy::\n-\tA \"proxy command\" to execute (as 'command host port') instead\n-\tof establishing direct connection to the remote server when\n-\tusing the git protocol for fetching. If the variable value is\n-\tin the \"COMMAND for DOMAIN\" format, the command is applied only\n-\ton hostnames ending with the specified domain string. This variable\n-\tmay be set multiple times and is matched in the given order;\n-\tthe first match wins.\n-+\n-Can be overridden by the 'GIT_PROXY_COMMAND' environment variable\n-(which always applies universally, without the special \"for\"\n-handling).\n-+\n-The special string `none` can be used as the proxy command to\n-specify that no proxy be used for a given domain pattern.\n-This is useful for excluding servers inside a firewall from\n-proxy use, while defaulting to a common proxy for external domains.\n+branch.autosetuprebase::\n+\tWhen a new branch is created with 'git branch' or 'git checkout'\n+\tthat tracks another branch, this variable tells git to set\n+\tup pull to rebase instead of merge (see \"branch.<name>.rebase\").\n+\tWhen `never`, rebase is never automatically set to true.\n+\tWhen `local`, rebase is set to true for tracked branches of\n+\tother local branches.\n+\tWhen `remote`, rebase is set to true for tracked branches of\n+\tremote-tracking branches.\n+\tWhen `always`, rebase will be set to true for all tracking\n+\tbranches.\n+\tSee \"branch.autosetupmerge\" for details on how to set up a\n+\tbranch to track another branch.\n+\tThis option defaults to never.\n \n-core.ignoreStat::\n-\tIf true, commands which modify both the working tree and the index\n-\twill mark the updated paths with the \"assume unchanged\" bit in the\n-\tindex. These marked files are then assumed to stay unchanged in the\n-\tworking copy, until you\tmark them otherwise manually - Git will not\n-\tdetect the file changes\tby lstat() calls. This is useful on systems\n-\twhere those are very slow, such as Microsoft Windows.\n-\tSee linkgit:git-update-index[1].\n-\tFalse by default.\n+browser.<tool>.cmd::\n+\tSpecify the command to invoke the specified browser. The\n+\tspecified command is evaluated in shell with the URLs passed\n+\tas arguments. (See linkgit:git-web--browse[1].)\n \n-core.preferSymlinkRefs::\n-\tInstead of the default \"symref\" format for HEAD\n-\tand other symbolic reference files, use symbolic links.\n-\tThis is sometimes needed to work with old scripts that\n-\texpect HEAD to be a symbolic link.\n+browser.<tool>.path::\n+\tOverride the path for the given tool that may be used to\n+\tbrowse HTML help (see '-w' option in linkgit:git-help[1]) or a\n+\tworking repository in gitweb (see linkgit:git-instaweb[1]).\n \n-core.bare::\n-\tIf true this repository is assumed to be 'bare' and has no\n-\tworking directory associated with it.  If this is the case a\n-\tnumber of commands that require a working directory will be\n-\tdisabled, such as linkgit:git-add[1] or linkgit:git-merge[1].\n-+\n-This setting is automatically guessed by linkgit:git-clone[1] or\n-linkgit:git-init[1] when the repository was created.  By default a\n-repository that ends in \"/.git\" is assumed to be not bare (bare =\n-false), while all other repositories are assumed to be bare (bare\n-= true).\n+clean.requireForce::\n+\tA boolean to make git-clean do nothing unless given -f\n+\tor -n.\t Defaults to true.\n \n-core.worktree::\n-\tSet the path to the root of the work tree.\n-\tThis can be overridden by the GIT_WORK_TREE environment\n-\tvariable and the '--work-tree' command line option. It can be\n-\tan absolute path or a relative path to the .git directory,\n-\teither specified by --git-dir or GIT_DIR, or automatically\n-\tdiscovered.\n-\tIf --git-dir or GIT_DIR are specified but none of\n-\t--work-tree, GIT_WORK_TREE and core.worktree is specified,\n-\tthe current working directory is regarded as the root of the\n-\twork tree.\n+color.branch::\n+\tA boolean to enable/disable color in the output of\n+\tlinkgit:git-branch[1]. May be set to `always`,\n+\t`false` (or `never`) or `auto` (or `true`), in which case colors are used\n+\tonly when the output is to a terminal. Defaults to false.\n+\n+color.branch.<slot>::\n+\tUse customized color for branch coloration. `<slot>` is one of\n+\t`current` (the current branch), `local` (a local branch),\n+\t`remote` (a remote-tracking branch in refs/remotes/), `plain` (other\n+\trefs).\n +\n-Note that this variable is honored even when set in a configuration\n-file in a \".git\" subdirectory of a directory, and its value differs\n-from the latter directory (e.g. \"/path/to/.git/config\" has\n-core.worktree set to \"/different/path\"), which is most likely a\n-misconfiguration.  Running git commands in \"/path/to\" directory will\n-still use \"/different/path\" as the root of the work tree and can cause\n-great confusion to the users.\n+The value for these configuration variables is a list of colors (at most\n+two) and attributes (at most one), separated by spaces.\t The colors\n+accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,\n+`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,\n+`blink` and `reverse`.\tThe first color given is the foreground; the\n+second is the background.  The position of the attribute, if any,\n+doesn't matter.\n+\n+color.decorate.<slot>::\n+\tUse customized color for 'git log --decorate' output.  `<slot>` is one\n+\tof `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local\n+\tbranches, remote-tracking branches, tags, stash and HEAD, respectively.\n+\n+color.diff::\n+\tWhen set to `always`, always use colors in patch.\n+\tWhen false (or `never`), never.\t When set to `true` or `auto`, use\n+\tcolors only when the output is to the terminal. Defaults to false.\n \n-core.logAllRefUpdates::\n-\tEnable the reflog. Updates to a ref <ref> is logged to the file\n-\t\"$GIT_DIR/logs/<ref>\", by appending the new and old\n-\tSHA1, the date/time and the reason of the update, but\n-\tonly when the file exists.  If this configuration\n-\tvariable is set to true, missing \"$GIT_DIR/logs/<ref>\"\n-\tfile is automatically created for branch heads.\n+color.diff.<slot>::\n+\tUse customized color for diff colorization.  `<slot>` specifies\n+\twhich part of the patch to use the specified color, and is one\n+\tof `plain` (context text), `meta` (metainformation), `frag`\n+\t(hunk header), 'func' (function in hunk header), `old` (removed lines),\n+\t`new` (added lines), `commit` (commit headers), or `whitespace`\n+\t(highlighting whitespace errors). The values of these variables may be\n+\tspecified as in color.branch.<slot>.\n+\n+color.grep::\n+\tWhen set to `always`, always highlight matches.\t When `false` (or\n+\t`never`), never.  When set to `true` or `auto`, use color only\n+\twhen the output is written to the terminal.  Defaults to `false`.\n+\n+color.grep.<slot>::\n+\tUse customized color for grep colorization.  `<slot>` specifies which\n+\tpart of the line to use the specified color, and is one of\n +\n-This information can be used to determine what commit\n-was the tip of a branch \"2 days ago\".\n+--\n+`context`;;\n+\tnon-matching text in context lines (when using `-A`, `-B`, or `-C`)\n+`filename`;;\n+\tfilename prefix (when not using `-h`)\n+`function`;;\n+\tfunction name lines (when using `-p`)\n+`linenumber`;;\n+\tline number prefix (when using `-n`)\n+`match`;;\n+\tmatching text\n+`selected`;;\n+\tnon-matching text in selected lines\n+`separator`;;\n+\tseparators between fields on a line (`:`, `-`, and `=`)\n+\tand between hunks (`--`)\n+--\n +\n-This value is true by default in a repository that has\n-a working directory associated with it, and false by\n-default in a bare repository.\n-\n-core.repositoryFormatVersion::\n-\tInternal variable identifying the repository format and layout\n-\tversion.\n+The values of these variables may be specified as in color.branch.<slot>.\n \n-core.sharedRepository::\n-\tWhen 'group' (or 'true'), the repository is made shareable between\n-\tseveral users in a group (making sure all the files and objects are\n-\tgroup-writable). When 'all' (or 'world' or 'everybody'), the\n-\trepository will be readable by all users, additionally to being\n-\tgroup-shareable. When 'umask' (or 'false'), git will use permissions\n-\treported by umask(2). When '0xxx', where '0xxx' is an octal number,\n-\tfiles in the repository will have this mode value. '0xxx' will override\n-\tuser's umask value (whereas the other options will only override\n-\trequested parts of the user's umask value). Examples: '0660' will make\n-\tthe repo read/write-able for the owner and group, but inaccessible to\n-\tothers (equivalent to 'group' unless umask is e.g. '0022'). '0640' is a\n-\trepository that is group-readable but not group-writable.\n-\tSee linkgit:git-init[1]. False by default.\n+color.interactive::\n+\tWhen set to `always`, always use colors for interactive prompts\n+\tand displays (such as those used by \"git-add --interactive\").\n+\tWhen false (or `never`), never.\t When set to `true` or `auto`, use\n+\tcolors only when the output is to the terminal. Defaults to false.\n \n-core.warnAmbiguousRefs::\n-\tIf true, git will warn you if the ref name you passed it is ambiguous\n-\tand might match multiple refs in the .git/refs/ tree. True by default.\n+color.interactive.<slot>::\n+\tUse customized color for 'git add --interactive'\n+\toutput. `<slot>` may be `prompt`, `header`, `help` or `error`, for\n+\tfour distinct types of normal output from interactive\n+\tcommands.  The values of these variables may be specified as\n+\tin color.branch.<slot>.\n \n-core.compression::\n-\tAn integer -1..9, indicating a default compression level.\n-\t-1 is the zlib default. 0 means no compression,\n-\tand 1..9 are various speed/size tradeoffs, 9 being slowest.\n-\tIf set, this provides a default to other compression variables,\n-\tsuch as 'core.loosecompression' and 'pack.compression'.\n+color.pager::\n+\tA boolean to enable/disable colored output when the pager is in\n+\tuse (default is true).\n \n-core.loosecompression::\n-\tAn integer -1..9, indicating the compression level for objects that\n-\tare not in a pack file. -1 is the zlib default. 0 means no\n-\tcompression, and 1..9 are various speed/size tradeoffs, 9 being\n-\tslowest.  If not set,  defaults to core.compression.  If that is\n-\tnot set,  defaults to 1 (best speed).\n+color.showbranch::\n+\tA boolean to enable/disable color in the output of\n+\tlinkgit:git-show-branch[1]. May be set to `always`,\n+\t`false` (or `never`) or `auto` (or `true`), in which case colors are used\n+\tonly when the output is to a terminal. Defaults to false.\n \n-core.packedGitWindowSize::\n-\tNumber of bytes of a pack file to map into memory in a\n-\tsingle mapping operation.  Larger window sizes may allow\n-\tyour system to process a smaller number of large pack files\n-\tmore quickly.  Smaller window sizes will negatively affect\n-\tperformance due to increased calls to the operating system's\n-\tmemory manager, but may improve performance when accessing\n-\ta large number of large pack files.\n-+\n-Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32\n-MiB on 32 bit platforms and 1 GiB on 64 bit platforms.  This should\n-be reasonable for all users/operating systems.  You probably do\n-not need to adjust this value.\n-+\n-Common unit suffixes of 'k', 'm', or 'g' are supported.\n+color.status::\n+\tA boolean to enable/disable color in the output of\n+\tlinkgit:git-status[1]. May be set to `always`,\n+\t`false` (or `never`) or `auto` (or `true`), in which case colors are used\n+\tonly when the output is to a terminal. Defaults to false.\n \n-core.packedGitLimit::\n-\tMaximum number of bytes to map simultaneously into memory\n-\tfrom pack files.  If Git needs to access more than this many\n-\tbytes at once to complete an operation it will unmap existing\n-\tregions to reclaim virtual address space within the process.\n-+\n-Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.\n-This should be reasonable for all users/operating systems, except on\n-the largest projects.  You probably do not need to adjust this value.\n-+\n-Common unit suffixes of 'k', 'm', or 'g' are supported.\n+color.status.<slot>::\n+\tUse customized color for status colorization. `<slot>` is\n+\tone of `header` (the header text of the status message),\n+\t`added` or `updated` (files which are added but not committed),\n+\t`changed` (files which are changed but not added in the index),\n+\t`untracked` (files which are not tracked by git), or\n+\t`nobranch` (the color the 'no branch' warning is shown in, defaulting\n+\tto red). The values of these variables may be specified as in\n+\tcolor.branch.<slot>.\n \n-core.deltaBaseCacheLimit::\n-\tMaximum number of bytes to reserve for caching base objects\n-\tthat may be referenced by multiple deltified objects.  By storing the\n-\tentire decompressed base objects in a cache Git is able\n-\tto avoid unpacking and decompressing frequently used base\n-\tobjects multiple times.\n-+\n-Default is 16 MiB on all platforms.  This should be reasonable\n-for all users/operating systems, except on the largest projects.\n-You probably do not need to adjust this value.\n-+\n-Common unit suffixes of 'k', 'm', or 'g' are supported.\n+color.ui::\n+\tWhen set to `always`, always use colors in all git commands which\n+\tare capable of colored output. When false (or `never`), never. When\n+\tset to `true` or `auto`, use colors only when the output is to the\n+\tterminal. When more specific variables of color.* are set, they always\n+\ttake precedence over this setting. Defaults to false.\n \n-core.bigFileThreshold::\n-\tFiles larger than this size are stored deflated, without\n-\tattempting delta compression.  Storing large files without\n-\tdelta compression avoids excessive memory usage, at the\n-\tslight expense of increased disk usage.\n-+\n-Default is 512 MiB on all platforms.  This should be reasonable\n-for most projects as source code and other text files can still\n-be delta compressed, but larger binary media files won't be.\n-+\n-Common unit suffixes of 'k', 'm', or 'g' are supported.\n-+\n-Currently only linkgit:git-fast-import[1] honors this setting.\n+commit.status::\n+\tA boolean to enable/disable inclusion of status information in the\n+\tcommit message template when using an editor to prepare the commit\n+\tmessage.  Defaults to true.\n \n-core.excludesfile::\n-\tIn addition to '.gitignore' (per-directory) and\n-\t'.git/info/exclude', git looks into this file for patterns\n-\tof files which are not meant to be tracked.  \"{tilde}/\" is expanded\n-\tto the value of `$HOME` and \"{tilde}user/\" to the specified user's\n-\thome directory.  See linkgit:gitignore[5].\n+commit.template::\n+\tSpecify a file to use as the template for new commit messages.\n+\t\"{tilde}/\" is expanded to the value of `$HOME` and \"{tilde}user/\" to the\n+\tspecified user's home directory.\n \n core.askpass::\n \tSome commands (e.g. svn and http interfaces) that interactively\n@@ -465,71 +403,48 @@ core.attributesfile::\n \t(see linkgit:gitattributes[5]). Path expansions are made the same\n \tway as for `core.excludesfile`.\n \n-core.editor::\n-\tCommands such as `commit` and `tag` that lets you edit\n-\tmessages by launching an editor uses the value of this\n-\tvariable when it is set, and the environment variable\n-\t`GIT_EDITOR` is not set.  See linkgit:git-var[1].\n-\n-core.pager::\n-\tThe command that git will use to paginate output.  Can\n-\tbe overridden with the `GIT_PAGER` environment\n-\tvariable.  Note that git sets the `LESS` environment\n-\tvariable to `FRSX` if it is unset when it runs the\n-\tpager.  One can change these settings by setting the\n-\t`LESS` variable to some other value.  Alternately,\n-\tthese settings can be overridden on a project or\n-\tglobal basis by setting the `core.pager` option.\n-\tSetting `core.pager` has no affect on the `LESS`\n-\tenvironment variable behaviour above, so if you want\n-\tto override git's default settings this way, you need\n-\tto be explicit.  For example, to disable the S option\n-\tin a backward compatible manner, set `core.pager`\n-\tto `less -+$LESS -FRX`.  This will be passed to the\n-\tshell by git, which will translate the final command to\n-\t`LESS=FRSX less -+FRSX -FRX`.\n+core.autocrlf::\n+\tSetting this variable to \"true\" is almost the same as setting\n+\tthe `text` attribute to \"auto\" on all files except that text\n+\tfiles are not guaranteed to be normalized: files that contain\n+\t`CRLF` in the repository will not be touched.  Use this\n+\tsetting if you want to have `CRLF` line endings in your\n+\tworking directory even though the repository does not have\n+\tnormalized line endings.  This variable can be set to 'input',\n+\tin which case no output conversion is performed.\n \n-core.whitespace::\n-\tA comma separated list of common whitespace problems to\n-\tnotice.  'git diff' will use `color.diff.whitespace` to\n-\thighlight them, and 'git apply --whitespace=error' will\n-\tconsider them as errors.  You can prefix `-` to disable\n-\tany of them (e.g. `-trailing-space`):\n+core.bare::\n+\tIf true this repository is assumed to be 'bare' and has no\n+\tworking directory associated with it.  If this is the case a\n+\tnumber of commands that require a working directory will be\n+\tdisabled, such as linkgit:git-add[1] or linkgit:git-merge[1].\n +\n-* `blank-at-eol` treats trailing whitespaces at the end of the line\n-  as an error (enabled by default).\n-* `space-before-tab` treats a space character that appears immediately\n-  before a tab character in the initial indent part of the line as an\n-  error (enabled by default).\n-* `indent-with-non-tab` treats a line that is indented with 8 or more\n-  space characters as an error (not enabled by default).\n-* `tab-in-indent` treats a tab character in the initial indent part of\n-  the line as an error (not enabled by default).\n-* `blank-at-eof` treats blank lines added at the end of file as an error\n-  (enabled by default).\n-* `trailing-space` is a short-hand to cover both `blank-at-eol` and\n-  `blank-at-eof`.\n-* `cr-at-eol` treats a carriage-return at the end of line as\n-  part of the line terminator, i.e. with it, `trailing-space`\n-  does not trigger if the character before such a carriage-return\n-  is not a whitespace (not enabled by default).\n+This setting is automatically guessed by linkgit:git-clone[1] or\n+linkgit:git-init[1] when the repository was created.  By default a\n+repository that ends in \"/.git\" is assumed to be not bare (bare =\n+false), while all other repositories are assumed to be bare (bare\n+= true).\n \n-core.fsyncobjectfiles::\n-\tThis boolean will enable 'fsync()' when writing object files.\n+core.bigFileThreshold::\n+\tFiles larger than this size are stored deflated, without\n+\tattempting delta compression.  Storing large files without\n+\tdelta compression avoids excessive memory usage, at the\n+\tslight expense of increased disk usage.\n +\n-This is a total waste of time and effort on a filesystem that orders\n-data writes properly, but can be useful for filesystems that do not use\n-journalling (traditional UNIX filesystems) or that only journal metadata\n-and not file contents (OS X's HFS+, or Linux ext3 with \"data=writeback\").\n-\n-core.preloadindex::\n-\tEnable parallel index preload for operations like 'git diff'\n+Default is 512 MiB on all platforms.  This should be reasonable\n+for most projects as source code and other text files can still\n+be delta compressed, but larger binary media files won't be.\n +\n-This can speed up operations like 'git diff' and 'git status' especially\n-on filesystems like NFS that have weak caching semantics and thus\n-relatively high IO latencies.  With this set to 'true', git will do the\n-index comparison to the filesystem data in parallel, allowing\n-overlapping IO's.\n+Common unit suffixes of 'k', 'm', or 'g' are supported.\n++\n+Currently only linkgit:git-fast-import[1] honors this setting.\n+\n+core.compression::\n+\tAn integer -1..9, indicating a default compression level.\n+\t-1 is the zlib default. 0 means no compression,\n+\tand 1..9 are various speed/size tradeoffs, 9 being slowest.\n+\tIf set, this provides a default to other compression variables,\n+\tsuch as 'core.loosecompression' and 'pack.compression'.\n \n core.createObject::\n \tYou can set this to 'link', in which case a hardlink followed by\n@@ -540,261 +455,346 @@ On some file system/operating system combinations, this is unreliable.\n Set this config setting to 'rename' there; However, This will remove the\n check that makes sure that existing object files will not get overwritten.\n \n-core.notesRef::\n-\tWhen showing commit messages, also show notes which are stored in\n-\tthe given ref.  The ref must be fully qualified.  If the given\n-\tref does not exist, it is not an error but means that no\n-\tnotes should be printed.\n+core.deltaBaseCacheLimit::\n+\tMaximum number of bytes to reserve for caching base objects\n+\tthat may be referenced by multiple deltified objects.  By storing the\n+\tentire decompressed base objects in a cache Git is able\n+\tto avoid unpacking and decompressing frequently used base\n+\tobjects multiple times.\n +\n-This setting defaults to \"refs/notes/commits\", and it can be overridden by\n-the 'GIT_NOTES_REF' environment variable.  See linkgit:git-notes[1].\n-\n-core.sparseCheckout::\n-\tEnable \"sparse checkout\" feature. See section \"Sparse checkout\" in\n-\tlinkgit:git-read-tree[1] for more information.\n-\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].\n-\n-alias.*::\n-\tCommand aliases for the linkgit:git[1] command wrapper - e.g.\n-\tafter defining \"alias.last = cat-file commit HEAD\", the invocation\n-\t\"git last\" is equivalent to \"git cat-file commit HEAD\". To avoid\n-\tconfusion and troubles with script usage, aliases that\n-\thide existing git commands are ignored. Arguments are split by\n-\tspaces, the usual shell quoting and escaping is supported.\n-\tquote pair and a backslash can be used to quote them.\n+Default is 16 MiB on all platforms.  This should be reasonable\n+for all users/operating systems, except on the largest projects.\n+You probably do not need to adjust this value.\n +\n-If the alias expansion is prefixed with an exclamation point,\n-it will be treated as a shell command.  For example, defining\n-\"alias.new = !gitk --all --not ORIG_HEAD\", the invocation\n-\"git new\" is equivalent to running the shell command\n-\"gitk --all --not ORIG_HEAD\".  Note that shell commands will be\n-executed from the top-level directory of a repository, which may\n-not necessarily be the current directory.\n+Common unit suffixes of 'k', 'm', or 'g' are supported.\n \n-am.keepcr::\n-\tIf true, git-am will call git-mailsplit for patches in mbox format\n-\twith parameter '--keep-cr'. In this case git-mailsplit will\n-\tnot remove `\\r` from lines ending with `\\r\\n`. Can be overridden\n-\tby giving '--no-keep-cr' from the command line.\n-\tSee linkgit:git-am[1], linkgit:git-mailsplit[1].\n+core.editor::\n+\tCommands such as `commit` and `tag` that lets you edit\n+\tmessages by launching an editor uses the value of this\n+\tvariable when it is set, and the environment variable\n+\t`GIT_EDITOR` is not set.  See linkgit:git-var[1].\n \n-apply.ignorewhitespace::\n-\tWhen set to 'change', tells 'git apply' to ignore changes in\n-\twhitespace, in the same way as the '--ignore-space-change'\n-\toption.\n-\tWhen set to one of: no, none, never, false tells 'git apply' to\n-\trespect all whitespace differences.\n-\tSee linkgit:git-apply[1].\n+core.eol::\n+\tSets the line ending type to use in the working directory for\n+\tfiles that have the `text` property set.  Alternatives are\n+\t'lf', 'crlf' and 'native', which uses the platform's native\n+\tline ending.  The default value is `native`.  See\n+\tlinkgit:gitattributes[5] for more information on end-of-line\n+\tconversion.\n \n-apply.whitespace::\n-\tTells 'git apply' how to handle whitespaces, in the same way\n-\tas the '--whitespace' option. See linkgit:git-apply[1].\n+core.excludesfile::\n+\tIn addition to '.gitignore' (per-directory) and\n+\t'.git/info/exclude', git looks into this file for patterns\n+\tof files which are not meant to be tracked.  \"{tilde}/\" is expanded\n+\tto the value of `$HOME` and \"{tilde}user/\" to the specified user's\n+\thome directory.\t See linkgit:gitignore[5].\n \n-branch.autosetupmerge::\n-\tTells 'git branch' and 'git checkout' to set up new branches\n-\tso that linkgit:git-pull[1] will appropriately merge from the\n-\tstarting point branch. Note that even if this option is not set,\n-\tthis behavior can be chosen per-branch using the `--track`\n-\tand `--no-track` options. The valid settings are: `false` -- no\n-\tautomatic setup is done; `true` -- automatic setup is done when the\n-\tstarting point is a remote-tracking branch; `always` --\n-\tautomatic setup is done when the starting point is either a\n-\tlocal branch or remote-tracking\n-\tbranch. This option defaults to true.\n+core.fileMode::\n+\tIf false, the executable bit differences between the index and\n+\tthe working copy are ignored; useful on broken filesystems like FAT.\n+\tSee linkgit:git-update-index[1].\n++\n+The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]\n+will probe and set core.fileMode false if appropriate when the\n+repository is created.\n \n-branch.autosetuprebase::\n-\tWhen a new branch is created with 'git branch' or 'git checkout'\n-\tthat tracks another branch, this variable tells git to set\n-\tup pull to rebase instead of merge (see \"branch.<name>.rebase\").\n-\tWhen `never`, rebase is never automatically set to true.\n-\tWhen `local`, rebase is set to true for tracked branches of\n-\tother local branches.\n-\tWhen `remote`, rebase is set to true for tracked branches of\n-\tremote-tracking branches.\n-\tWhen `always`, rebase will be set to true for all tracking\n-\tbranches.\n-\tSee \"branch.autosetupmerge\" for details on how to set up a\n-\tbranch to track another branch.\n-\tThis option defaults to never.\n+ core.fsyncobjectfiles::\n+\tThis boolean will enable 'fsync()' when writing object files.\n++\n+This is a total waste of time and effort on a filesystem that orders\n+data writes properly, but can be useful for filesystems that do not use\n+journalling (traditional UNIX filesystems) or that only journal metadata\n+and not file contents (OS X's HFS+, or Linux ext3 with \"data=writeback\").\n \n-branch.<name>.remote::\n-\tWhen in branch <name>, it tells 'git fetch' and 'git push' which\n-\tremote to fetch from/push to.  It defaults to `origin` if no remote is\n-\tconfigured. `origin` is also used if you are not on any branch.\n+core.gitProxy::\n+\tA \"proxy command\" to execute (as 'command host port') instead\n+\tof establishing direct connection to the remote server when\n+\tusing the git protocol for fetching. If the variable value is\n+\tin the \"COMMAND for DOMAIN\" format, the command is applied only\n+\ton hostnames ending with the specified domain string. This variable\n+\tmay be set multiple times and is matched in the given order;\n+\tthe first match wins.\n++\n+Can be overridden by the 'GIT_PROXY_COMMAND' environment variable\n+(which always applies universally, without the special \"for\"\n+handling).\n++\n+The special string `none` can be used as the proxy command to\n+specify that no proxy be used for a given domain pattern.\n+This is useful for excluding servers inside a firewall from\n+proxy use, while defaulting to a common proxy for external domains.\n \n-branch.<name>.merge::\n-\tDefines, together with branch.<name>.remote, the upstream branch\n-\tfor the given branch. It tells 'git fetch'/'git pull' which\n-\tbranch to merge and can also affect 'git push' (see push.default).\n-\tWhen in branch <name>, it tells 'git fetch' the default\n-\trefspec to be marked for merging in FETCH_HEAD. The value is\n-\thandled like the remote part of a refspec, and must match a\n-\tref which is fetched from the remote given by\n-\t\"branch.<name>.remote\".\n-\tThe merge information is used by 'git pull' (which at first calls\n-\t'git fetch') to lookup the default branch for merging. Without\n-\tthis option, 'git pull' defaults to merge the first refspec fetched.\n-\tSpecify multiple values to get an octopus merge.\n-\tIf you wish to setup 'git pull' so that it merges into <name> from\n-\tanother branch in the local repository, you can point\n-\tbranch.<name>.merge to the desired branch, and use the special setting\n-\t`.` (a period) for branch.<name>.remote.\n+core.ignorecase::\n+\tIf true, this option enables various workarounds to enable\n+\tgit to work better on filesystems that are not case sensitive,\n+\tlike FAT. For example, if a directory listing finds\n+\t\"makefile\" when git expects \"Makefile\", git will assume\n+\tit is really the same file, and continue to remember it as\n+\t\"Makefile\".\n++\n+The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]\n+will probe and set core.ignorecase true if appropriate when the repository\n+is created.\n \n-branch.<name>.mergeoptions::\n-\tSets default options for merging into branch <name>. The syntax and\n-\tsupported options are the same as those of linkgit:git-merge[1], but\n-\toption values containing whitespace characters are currently not\n-\tsupported.\n+core.ignoreCygwinFSTricks::\n+\tThis option is only used by Cygwin implementation of Git. If false,\n+\tthe Cygwin stat() and lstat() functions are used. This may be useful\n+\tif your repository consists of a few separate directories joined in\n+\tone hierarchy using Cygwin mount. If true, Git uses native Win32 API\n+\twhenever it is possible and falls back to Cygwin functions only to\n+\thandle symbol links. The native mode is more than twice faster than\n+\tnormal Cygwin l/stat() functions. True by default, unless core.filemode\n+\tis true, in which case ignoreCygwinFSTricks is ignored as Cygwin's\n+\tPOSIX emulation is required to support core.filemode.\n \n-branch.<name>.rebase::\n-\tWhen true, rebase the branch <name> on top of the fetched branch,\n-\tinstead of merging the default branch from the default remote when\n-\t\"git pull\" is run.\n-\t*NOTE*: this is a possibly dangerous operation; do *not* use\n-\tit unless you understand the implications (see linkgit:git-rebase[1]\n-\tfor details).\n+core.ignoreStat::\n+\tIf true, commands which modify both the working tree and the index\n+\twill mark the updated paths with the \"assume unchanged\" bit in the\n+\tindex. These marked files are then assumed to stay unchanged in the\n+\tworking copy, until you\tmark them otherwise manually - Git will not\n+\tdetect the file changes\tby lstat() calls. This is useful on systems\n+\twhere those are very slow, such as Microsoft Windows.\n+\tSee linkgit:git-update-index[1].\n+\tFalse by default.\n \n-browser.<tool>.cmd::\n-\tSpecify the command to invoke the specified browser. The\n-\tspecified command is evaluated in shell with the URLs passed\n-\tas arguments. (See linkgit:git-web--browse[1].)\n+core.logAllRefUpdates::\n+\tEnable the reflog. Updates to a ref <ref> is logged to the file\n+\t\"$GIT_DIR/logs/<ref>\", by appending the new and old\n+\tSHA1, the date/time and the reason of the update, but\n+\tonly when the file exists.  If this configuration\n+\tvariable is set to true, missing \"$GIT_DIR/logs/<ref>\"\n+\tfile is automatically created for branch heads.\n++\n+This information can be used to determine what commit\n+was the tip of a branch \"2 days ago\".\n++\n+This value is true by default in a repository that has\n+a working directory associated with it, and false by\n+default in a bare repository.\n \n-browser.<tool>.path::\n-\tOverride the path for the given tool that may be used to\n-\tbrowse HTML help (see '-w' option in linkgit:git-help[1]) or a\n-\tworking repository in gitweb (see linkgit:git-instaweb[1]).\n+core.loosecompression::\n+\tAn integer -1..9, indicating the compression level for objects that\n+\tare not in a pack file. -1 is the zlib default. 0 means no\n+\tcompression, and 1..9 are various speed/size tradeoffs, 9 being\n+\tslowest.  If not set,  defaults to core.compression.  If that is\n+\tnot set,  defaults to 1 (best speed).\n \n-clean.requireForce::\n-\tA boolean to make git-clean do nothing unless given -f\n-\tor -n.   Defaults to true.\n+core.notesRef::\n+\tWhen showing commit messages, also show notes which are stored in\n+\tthe given ref.\tThe ref must be fully qualified.  If the given\n+\tref does not exist, it is not an error but means that no\n+\tnotes should be printed.\n++\n+This setting defaults to \"refs/notes/commits\", and it can be overridden by\n+the 'GIT_NOTES_REF' environment variable.  See linkgit:git-notes[1].\n \n-color.branch::\n-\tA boolean to enable/disable color in the output of\n-\tlinkgit:git-branch[1]. May be set to `always`,\n-\t`false` (or `never`) or `auto` (or `true`), in which case colors are used\n-\tonly when the output is to a terminal. Defaults to false.\n+core.packedGitLimit::\n+\tMaximum number of bytes to map simultaneously into memory\n+\tfrom pack files.  If Git needs to access more than this many\n+\tbytes at once to complete an operation it will unmap existing\n+\tregions to reclaim virtual address space within the process.\n++\n+Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.\n+This should be reasonable for all users/operating systems, except on\n+the largest projects.  You probably do not need to adjust this value.\n++\n+Common unit suffixes of 'k', 'm', or 'g' are supported.\n \n-color.branch.<slot>::\n-\tUse customized color for branch coloration. `<slot>` is one of\n-\t`current` (the current branch), `local` (a local branch),\n-\t`remote` (a remote-tracking branch in refs/remotes/), `plain` (other\n-\trefs).\n+core.packedGitWindowSize::\n+\tNumber of bytes of a pack file to map into memory in a\n+\tsingle mapping operation.  Larger window sizes may allow\n+\tyour system to process a smaller number of large pack files\n+\tmore quickly.  Smaller window sizes will negatively affect\n+\tperformance due to increased calls to the operating system's\n+\tmemory manager, but may improve performance when accessing\n+\ta large number of large pack files.\n +\n-The value for these configuration variables is a list of colors (at most\n-two) and attributes (at most one), separated by spaces.  The colors\n-accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,\n-`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,\n-`blink` and `reverse`.  The first color given is the foreground; the\n-second is the background.  The position of the attribute, if any,\n-doesn't matter.\n+Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32\n+MiB on 32 bit platforms and 1 GiB on 64 bit platforms.\tThis should\n+be reasonable for all users/operating systems.\tYou probably do\n+not need to adjust this value.\n++\n+Common unit suffixes of 'k', 'm', or 'g' are supported.\n \n-color.diff::\n-\tWhen set to `always`, always use colors in patch.\n-\tWhen false (or `never`), never.  When set to `true` or `auto`, use\n-\tcolors only when the output is to the terminal. Defaults to false.\n+core.pager::\n+\tThe command that git will use to paginate output.  Can\n+\tbe overridden with the `GIT_PAGER` environment\n+\tvariable.  Note that git sets the `LESS` environment\n+\tvariable to `FRSX` if it is unset when it runs the\n+\tpager.\tOne can change these settings by setting the\n+\t`LESS` variable to some other value.  Alternately,\n+\tthese settings can be overridden on a project or\n+\tglobal basis by setting the `core.pager` option.\n+\tSetting `core.pager` has no affect on the `LESS`\n+\tenvironment variable behaviour above, so if you want\n+\tto override git's default settings this way, you need\n+\tto be explicit.\t For example, to disable the S option\n+\tin a backward compatible manner, set `core.pager`\n+\tto `less -+$LESS -FRX`.\t This will be passed to the\n+\tshell by git, which will translate the final command to\n+\t`LESS=FRSX less -+FRSX -FRX`.\n \n-color.diff.<slot>::\n-\tUse customized color for diff colorization.  `<slot>` specifies\n-\twhich part of the patch to use the specified color, and is one\n-\tof `plain` (context text), `meta` (metainformation), `frag`\n-\t(hunk header), 'func' (function in hunk header), `old` (removed lines),\n-\t`new` (added lines), `commit` (commit headers), or `whitespace`\n-\t(highlighting whitespace errors). The values of these variables may be\n-\tspecified as in color.branch.<slot>.\n+core.preferSymlinkRefs::\n+\tInstead of the default \"symref\" format for HEAD\n+\tand other symbolic reference files, use symbolic links.\n+\tThis is sometimes needed to work with old scripts that\n+\texpect HEAD to be a symbolic link.\n \n-color.decorate.<slot>::\n-\tUse customized color for 'git log --decorate' output.  `<slot>` is one\n-\tof `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local\n-\tbranches, remote-tracking branches, tags, stash and HEAD, respectively.\n+core.preloadindex::\n+\tEnable parallel index preload for operations like 'git diff'\n++\n+This can speed up operations like 'git diff' and 'git status' especially\n+on filesystems like NFS that have weak caching semantics and thus\n+relatively high IO latencies.  With this set to 'true', git will do the\n+index comparison to the filesystem data in parallel, allowing\n+overlapping IO's.\n \n-color.grep::\n-\tWhen set to `always`, always highlight matches.  When `false` (or\n-\t`never`), never.  When set to `true` or `auto`, use color only\n-\twhen the output is written to the terminal.  Defaults to `false`.\n+core.quotepath::\n+\tThe commands that output paths (e.g. 'ls-files',\n+\t'diff'), when not given the `-z` option, will quote\n+\t\"unusual\" characters in the pathname by enclosing the\n+\tpathname in a double-quote pair and with backslashes the\n+\tsame way strings in C source code are quoted.  If this\n+\tvariable is set to false, the bytes higher than 0x80 are\n+\tnot quoted but output as verbatim.  Note that double\n+\tquote, backslash and control characters are always\n+\tquoted without `-z` regardless of the setting of this\n+\tvariable.\n \n-color.grep.<slot>::\n-\tUse customized color for grep colorization.  `<slot>` specifies which\n-\tpart of the line to use the specified color, and is one of\n+core.repositoryFormatVersion::\n+\tInternal variable identifying the repository format and layout\n+\tversion.\n+\n+core.safecrlf::\n+\tIf true, makes git check if converting `CRLF` is reversible when\n+\tend-of-line conversion is active.  Git will verify if a command\n+\tmodifies a file in the work tree either directly or indirectly.\n+\tFor example, committing a file followed by checking out the\n+\tsame file should yield the original file in the work tree.  If\n+\tthis is not the case for the current setting of\n+\t`core.autocrlf`, git will reject the file.  The variable can\n+\tbe set to \"warn\", in which case git will only warn about an\n+\tirreversible conversion but continue the operation.\n +\n---\n-`context`;;\n-\tnon-matching text in context lines (when using `-A`, `-B`, or `-C`)\n-`filename`;;\n-\tfilename prefix (when not using `-h`)\n-`function`;;\n-\tfunction name lines (when using `-p`)\n-`linenumber`;;\n-\tline number prefix (when using `-n`)\n-`match`;;\n-\tmatching text\n-`selected`;;\n-\tnon-matching text in selected lines\n-`separator`;;\n-\tseparators between fields on a line (`:`, `-`, and `=`)\n-\tand between hunks (`--`)\n---\n+CRLF conversion bears a slight chance of corrupting data.\n+When it is enabled, git will convert CRLF to LF during commit and LF to\n+CRLF during checkout.  A file that contains a mixture of LF and\n+CRLF before the commit cannot be recreated by git.  For text\n+files this is the right thing to do: it corrects line endings\n+such that we have only LF line endings in the repository.\n+But for binary files that are accidentally classified as text the\n+conversion can corrupt data.\n +\n-The values of these variables may be specified as in color.branch.<slot>.\n-\n-color.interactive::\n-\tWhen set to `always`, always use colors for interactive prompts\n-\tand displays (such as those used by \"git-add --interactive\").\n-\tWhen false (or `never`), never.  When set to `true` or `auto`, use\n-\tcolors only when the output is to the terminal. Defaults to false.\n-\n-color.interactive.<slot>::\n-\tUse customized color for 'git add --interactive'\n-\toutput. `<slot>` may be `prompt`, `header`, `help` or `error`, for\n-\tfour distinct types of normal output from interactive\n-\tcommands.  The values of these variables may be specified as\n-\tin color.branch.<slot>.\n+If you recognize such corruption early you can easily fix it by\n+setting the conversion type explicitly in .gitattributes.  Right\n+after committing you still have the original file in your work\n+tree and this file is not yet corrupted.  You can explicitly tell\n+git that this file is binary and git will handle the file\n+appropriately.\n++\n+Unfortunately, the desired effect of cleaning up text files with\n+mixed line endings and the undesired effect of corrupting binary\n+files cannot be distinguished.\tIn both cases CRLFs are removed\n+in an irreversible way.\t For text files this is the right thing\n+to do because CRLFs are line endings, while for binary files\n+converting CRLFs corrupts data.\n++\n+Note, this safety check does not mean that a checkout will generate a\n+file identical to the original file for a different setting of\n+`core.eol` and `core.autocrlf`, but only for the current one.  For\n+example, a text file with `LF` would be accepted with `core.eol=lf`\n+and could later be checked out with `core.eol=crlf`, in which case the\n+resulting file would contain `CRLF`, although the original file\n+contained `LF`.\t However, in both work trees the line endings would be\n+consistent, that is either all `LF` or all `CRLF`, but never mixed.  A\n+file with mixed line endings would be reported by the `core.safecrlf`\n+mechanism.\n \n-color.pager::\n-\tA boolean to enable/disable colored output when the pager is in\n-\tuse (default is true).\n+core.sharedRepository::\n+\tWhen 'group' (or 'true'), the repository is made shareable between\n+\tseveral users in a group (making sure all the files and objects are\n+\tgroup-writable). When 'all' (or 'world' or 'everybody'), the\n+\trepository will be readable by all users, additionally to being\n+\tgroup-shareable. When 'umask' (or 'false'), git will use permissions\n+\treported by umask(2). When '0xxx', where '0xxx' is an octal number,\n+\tfiles in the repository will have this mode value. '0xxx' will override\n+\tuser's umask value (whereas the other options will only override\n+\trequested parts of the user's umask value). Examples: '0660' will make\n+\tthe repo read/write-able for the owner and group, but inaccessible to\n+\tothers (equivalent to 'group' unless umask is e.g. '0022'). '0640' is a\n+\trepository that is group-readable but not group-writable.\n+\tSee linkgit:git-init[1]. False by default.\n \n-color.showbranch::\n-\tA boolean to enable/disable color in the output of\n-\tlinkgit:git-show-branch[1]. May be set to `always`,\n-\t`false` (or `never`) or `auto` (or `true`), in which case colors are used\n-\tonly when the output is to a terminal. Defaults to false.\n+core.sparseCheckout::\n+\tEnable \"sparse checkout\" feature. See section \"Sparse checkout\" in\n+\tlinkgit:git-read-tree[1] for more information.\n \n-color.status::\n-\tA boolean to enable/disable color in the output of\n-\tlinkgit:git-status[1]. May be set to `always`,\n-\t`false` (or `never`) or `auto` (or `true`), in which case colors are used\n-\tonly when the output is to a terminal. Defaults to false.\n+core.symlinks::\n+\tIf false, symbolic links are checked out as small plain files that\n+\tcontain the link text. linkgit:git-update-index[1] and\n+\tlinkgit:git-add[1] will not change the recorded type to regular\n+\tfile. Useful on filesystems like FAT that do not support\n+\tsymbolic links.\n++\n+The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]\n+will probe and set core.symlinks false if appropriate when the repository\n+is created.\n \n-color.status.<slot>::\n-\tUse customized color for status colorization. `<slot>` is\n-\tone of `header` (the header text of the status message),\n-\t`added` or `updated` (files which are added but not committed),\n-\t`changed` (files which are changed but not added in the index),\n-\t`untracked` (files which are not tracked by git), or\n-\t`nobranch` (the color the 'no branch' warning is shown in, defaulting\n-\tto red). The values of these variables may be specified as in\n-\tcolor.branch.<slot>.\n+core.trustctime::\n+\tIf false, the ctime differences between the index and the\n+\tworking copy are ignored; useful when the inode change time\n+\tis regularly modified by something outside Git (file system\n+\tcrawlers and some backup systems).\n+\tSee linkgit:git-update-index[1]. True by default.\n \n-color.ui::\n-\tWhen set to `always`, always use colors in all git commands which\n-\tare capable of colored output. When false (or `never`), never. When\n-\tset to `true` or `auto`, use colors only when the output is to the\n-\tterminal. When more specific variables of color.* are set, they always\n-\ttake precedence over this setting. Defaults to false.\n+core.warnAmbiguousRefs::\n+\tIf true, git will warn you if the ref name you passed it is ambiguous\n+\tand might match multiple refs in the .git/refs/ tree. True by default.\n \n-commit.status::\n-\tA boolean to enable/disable inclusion of status information in the\n-\tcommit message template when using an editor to prepare the commit\n-\tmessage.  Defaults to true.\n+core.whitespace::\n+\tA comma separated list of common whitespace problems to\n+\tnotice.\t 'git diff' will use `color.diff.whitespace` to\n+\thighlight them, and 'git apply --whitespace=error' will\n+\tconsider them as errors.  You can prefix `-` to disable\n+\tany of them (e.g. `-trailing-space`):\n++\n+* `blank-at-eol` treats trailing whitespaces at the end of the line\n+  as an error (enabled by default).\n+* `space-before-tab` treats a space character that appears immediately\n+  before a tab character in the initial indent part of the line as an\n+  error (enabled by default).\n+* `indent-with-non-tab` treats a line that is indented with 8 or more\n+  space characters as an error (not enabled by default).\n+* `tab-in-indent` treats a tab character in the initial indent part of\n+  the line as an error (not enabled by default).\n+* `blank-at-eof` treats blank lines added at the end of file as an error\n+  (enabled by default).\n+* `trailing-space` is a short-hand to cover both `blank-at-eol` and\n+  `blank-at-eof`.\n+* `cr-at-eol` treats a carriage-return at the end of line as\n+  part of the line terminator, i.e. with it, `trailing-space`\n+  does not trigger if the character before such a carriage-return\n+  is not a whitespace (not enabled by default).\n \n-commit.template::\n-\tSpecify a file to use as the template for new commit messages.\n-\t\"{tilde}/\" is expanded to the value of `$HOME` and \"{tilde}user/\" to the\n-\tspecified user's home directory.\n+core.worktree::\n+\tSet the path to the root of the work tree.\n+\tThis can be overridden by the GIT_WORK_TREE environment\n+\tvariable and the '--work-tree' command line option. It can be\n+\tan absolute path or a relative path to the .git directory,\n+\teither specified by --git-dir or GIT_DIR, or automatically\n+\tdiscovered.\n+\tIf --git-dir or GIT_DIR are specified but none of\n+\t--work-tree, GIT_WORK_TREE and core.worktree is specified,\n+\tthe current working directory is regarded as the root of the\n+\twork tree.\n++\n+Note that this variable is honored even when set in a configuration\n+file in a \".git\" subdirectory of a directory, and its value differs\n+from the latter directory (e.g. \"/path/to/.git/config\" has\n+core.worktree set to \"/different/path\"), which is most likely a\n+misconfiguration.  Running git commands in \"/path/to\" directory will\n+still use \"/different/path\" as the root of the work tree and can cause\n+great confusion to the users.\n \n diff.autorefreshindex::\n \tWhen using 'git diff' to compare with work tree\n@@ -802,19 +802,25 @@ diff.autorefreshindex::\n \tInstead, silently run `git update-index --refresh` to\n \tupdate the cached stat information for paths whose\n \tcontents in the work tree match the contents in the\n-\tindex.  This option defaults to true.  Note that this\n+\tindex.\tThis option defaults to true.  Note that this\n \taffects only 'git diff' Porcelain, and not lower level\n \t'diff' commands such as 'git diff-files'.\n \n diff.external::\n \tIf this config variable is set, diff generation is not\n \tperformed using the internal diff machinery, but using the\n-\tgiven command.  Can be overridden with the `GIT_EXTERNAL_DIFF'\n+\tgiven command.\tCan be overridden with the `GIT_EXTERNAL_DIFF'\n \tenvironment variable.  The command is called with parameters\n \tas described under \"git Diffs\" in linkgit:git[1].  Note: if\n \tyou want to use an external diff program only on a subset of\n \tyour files, you\tmight want to use linkgit:gitattributes[5] instead.\n \n+diff.ignoreSubmodules::\n+\tSets the default value of --ignore-submodules. Note that this\n+\taffects only 'git diff' Porcelain, and not lower level 'diff'\n+\tcommands such as 'git diff-files'. 'git checkout' also honors\n+\tthis setting when reporting uncommitted changes.\n+\n diff.mnemonicprefix::\n \tIf set, 'git diff' uses a prefix pair that is different from the\n \tstandard \"a/\" and \"b/\" depending on what is being compared.  When\n@@ -843,12 +849,6 @@ diff.renames::\n \twill enable basic rename detection.  If set to \"copies\" or\n \t\"copy\", it will detect copies, as well.\n \n-diff.ignoreSubmodules::\n-\tSets the default value of --ignore-submodules. Note that this\n-\taffects only 'git diff' Porcelain, and not lower level 'diff'\n-\tcommands such as 'git diff-files'. 'git checkout' also honors\n-\tthis setting when reporting uncommitted changes.\n-\n diff.suppressBlankEmpty::\n \tA boolean to inhibit the standard behavior of printing a space\n \tbefore each empty output line. Defaults to false.\n@@ -859,10 +859,6 @@ diff.tool::\n \tthe same valid values as `merge.tool` minus \"tortoisemerge\"\n \tand plus \"kompare\".\n \n-difftool.<tool>.path::\n-\tOverride the path for the given tool.  This is useful in case\n-\tyour tool is not in the PATH.\n-\n difftool.<tool>.cmd::\n \tSpecify the command to invoke the specified diff tool.\n \tThe specified command is evaluated in shell with the following\n@@ -871,6 +867,10 @@ difftool.<tool>.cmd::\n \tis set to the name of the temporary file containing the contents\n \tof the diff post-image.\n \n+difftool.<tool>.path::\n+\tOverride the path for the given tool.  This is useful in case\n+\tyour tool is not in the PATH.\n+\n difftool.prompt::\n \tPrompt before each invocation of the diff tool.\n \n@@ -888,36 +888,32 @@ fetch.unpackLimit::\n \texceeds this limit then the received pack will be stored as\n \ta pack, after adding any missing delta bases.  Storing the\n \tpack from a push can make the push operation complete faster,\n-\tespecially on slow filesystems.  If not set, the value of\n+\tespecially on slow filesystems.\t If not set, the value of\n \t`transfer.unpackLimit` is used instead.\n \n format.attach::\n \tEnable multipart/mixed attachments as the default for\n-\t'format-patch'.  The value can also be a double quoted string\n+\t'format-patch'.\t The value can also be a double quoted string\n \twhich will enable attachments as the default and set the\n-\tvalue as the boundary.  See the --attach option in\n+\tvalue as the boundary.\tSee the --attach option in\n \tlinkgit:git-format-patch[1].\n \n+format.headers::\n+\tAdditional email headers to include in a patch to be submitted\n+\tby mail.  See linkgit:git-format-patch[1]. See also\n+\tformat.to and format.cc.\n+\n format.numbered::\n \tA boolean which can enable or disable sequence numbers in patch\n \tsubjects.  It defaults to \"auto\" which enables it only if there\n-\tis more than one patch.  It can be enabled or disabled for all\n+\tis more than one patch.\t It can be enabled or disabled for all\n \tmessages by setting it to \"true\" or \"false\".  See --numbered\n \toption in linkgit:git-format-patch[1].\n \n-format.headers::\n-\tAdditional email headers to include in a patch to be submitted\n-\tby mail.  See linkgit:git-format-patch[1].\n-\n-format.to::\n-format.cc::\n-\tAdditional recipients to include in a patch to be submitted\n-\tby mail.  See the --to and --cc options in\n-\tlinkgit:git-format-patch[1].\n-\n-format.subjectprefix::\n-\tThe default for format-patch is to output files with the '[PATCH]'\n-\tsubject prefix. Use this variable to change that prefix.\n+format.pretty::\n+\tThe default pretty format for log/show/whatchanged command,\n+\tSee linkgit:git-log[1], linkgit:git-show[1],\n+\tlinkgit:git-whatchanged[1].\n \n format.signature::\n \tThe default for format-patch is to output a signature containing\n@@ -925,16 +921,22 @@ format.signature::\n \tSet this variable to the empty string (\"\") to suppress\n \tsignature generation.\n \n+format.signoff::\n+    A boolean value which lets you enable the `-s/--signoff` option of\n+    format-patch by default. *Note:* Adding the Signed-off-by: line to a\n+    patch should be a conscious act and means that you certify you have\n+    the rights to submit this work under the same open source license.\n+    Please see the 'SubmittingPatches' document for further discussion.\n+\n+format.subjectprefix::\n+\tThe default for format-patch is to output files with the '[PATCH]'\n+\tsubject prefix. Use this variable to change that prefix.\n+\n format.suffix::\n \tThe default for format-patch is to output files with the suffix\n \t`.patch`. Use this variable to change that suffix (make sure to\n \tinclude the dot if you want it).\n \n-format.pretty::\n-\tThe default pretty format for log/show/whatchanged command,\n-\tSee linkgit:git-log[1], linkgit:git-show[1],\n-\tlinkgit:git-whatchanged[1].\n-\n format.thread::\n \tThe default threading style for 'git format-patch'.  Can be\n \ta boolean value, or `shallow` or `deep`.  `shallow` threading\n@@ -945,12 +947,11 @@ format.thread::\n \tA true boolean value is the same as `shallow`, and a false\n \tvalue disables threading.\n \n-format.signoff::\n-    A boolean value which lets you enable the `-s/--signoff` option of\n-    format-patch by default. *Note:* Adding the Signed-off-by: line to a\n-    patch should be a conscious act and means that you certify you have\n-    the rights to submit this work under the same open source license.\n-    Please see the 'SubmittingPatches' document for further discussion.\n+format.to::\n+format.cc::\n+\tAdditional recipients to include in a patch to be submitted\n+\tby mail.  See the --to and --cc options in\n+\tlinkgit:git-format-patch[1]. See also format.headers.\n \n gc.aggressiveWindow::\n \tThe window size parameter used in the delta compression\n@@ -962,12 +963,12 @@ gc.auto::\n \tobjects in the repository, `git gc --auto` will pack them.\n \tSome Porcelain commands use this command to perform a\n \tlight-weight garbage collection from time to time.  The\n-\tdefault value is 6700.  Setting this to 0 disables it.\n+\tdefault value is 6700.\tSetting this to 0 disables it.\n \n gc.autopacklimit::\n \tWhen there are more than this many packs that are not\n \tmarked with `*.keep` file in the repository, `git gc\n-\t--auto` consolidates them into one larger pack.  The\n+\t--auto` consolidates them into one larger pack.\t The\n \tdefault\tvalue is 50.  Setting this to 0 disables it.\n \n gc.packrefs::\n@@ -976,7 +977,7 @@ gc.packrefs::\n \ttransports such as HTTP.  This variable determines whether\n \t'git gc' runs `git pack-refs`. This can be set to `nobare`\n \tto enable it within all non-bare repos or it can be set to a\n-\tboolean value.  The default is `true`.\n+\tboolean value.\tThe default is `true`.\n \n gc.pruneexpire::\n \tWhen 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.\n@@ -987,7 +988,7 @@ gc.pruneexpire::\n gc.reflogexpire::\n gc.<pattern>.reflogexpire::\n \t'git reflog expire' removes reflog entries older than\n-\tthis time; defaults to 90 days.  With \"<pattern>\" (e.g.\n+\tthis time; defaults to 90 days.\t With \"<pattern>\" (e.g.\n \t\"refs/stash\") in the middle the setting applies only to\n \tthe refs that match the <pattern>.\n \n@@ -1002,35 +1003,12 @@ gc.<ref>.reflogexpireunreachable::\n gc.rerereresolved::\n \tRecords of conflicted merge you resolved earlier are\n \tkept for this many days when 'git rerere gc' is run.\n-\tThe default is 60 days.  See linkgit:git-rerere[1].\n+\tThe default is 60 days.\t See linkgit:git-rerere[1].\n \n gc.rerereunresolved::\n \tRecords of conflicted merge you have not resolved are\n \tkept for this many days when 'git rerere gc' is run.\n-\tThe default is 15 days.  See linkgit:git-rerere[1].\n-\n-gitcvs.commitmsgannotation::\n-\tAppend this string to each commit message. Set to empty string\n-\tto disable this feature. Defaults to \"via git-CVS emulator\".\n-\n-gitcvs.enabled::\n-\tWhether the CVS server interface is enabled for this repository.\n-\tSee linkgit:git-cvsserver[1].\n-\n-gitcvs.logfile::\n-\tPath to a log file where the CVS server interface well... logs\n-\tvarious stuff. See linkgit:git-cvsserver[1].\n-\n-gitcvs.usecrlfattr::\n-\tIf true, the server will look up the end-of-line conversion\n-\tattributes for files to determine the '-k' modes to use. If\n-\tthe attributes force git to treat a file as text,\n-\tthe '-k' mode will be left blank so CVS clients will\n-\ttreat it as text. If they suppress text conversion, the file\n-\twill be set with '-kb' mode, which suppresses any newline munging\n-\tthe client might otherwise do. If the attributes do not allow\n-\tthe file type to be determined, then 'gitcvs.allbinary' is\n-\tused. See linkgit:gitattributes[5].\n+\tThe default is 15 days.\t See linkgit:git-rerere[1].\n \n gitcvs.allbinary::\n \tThis is used if 'gitcvs.usecrlfattr' does not resolve\n@@ -1042,22 +1020,26 @@ gitcvs.allbinary::\n \tthen the contents of the file are examined to decide if\n \tit is binary, similar to 'core.autocrlf'.\n \n-gitcvs.dbname::\n-\tDatabase used by git-cvsserver to cache revision information\n-\tderived from the git repository. The exact meaning depends on the\n-\tused database driver, for SQLite (which is the default driver) this\n-\tis a filename. Supports variable substitution (see\n-\tlinkgit:git-cvsserver[1] for details). May not contain semicolons (`;`).\n-\tDefault: '%Ggitcvs.%m.sqlite'\n+gitcvs.commitmsgannotation::\n+\tAppend this string to each commit message. Set to empty string\n+\tto disable this feature. Defaults to \"via git-CVS emulator\".\n \n gitcvs.dbdriver::\n \tUsed Perl DBI driver. You can specify any available driver\n-        for this here, but it might not work. git-cvsserver is tested\n+\tfor this here, but it might not work. git-cvsserver is tested\n \twith 'DBD::SQLite', reported to work with 'DBD::Pg', and\n \treported *not* to work with 'DBD::mysql'. Experimental feature.\n \tMay not contain double colons (`:`). Default: 'SQLite'.\n \tSee linkgit:git-cvsserver[1].\n \n+gitcvs.dbname::\n+\tDatabase used by git-cvsserver to cache revision information\n+\tderived from the git repository. The exact meaning depends on the\n+\tused database driver, for SQLite (which is the default driver) this\n+\tis a filename. Supports variable substitution (see\n+\tlinkgit:git-cvsserver[1] for details). May not contain semicolons (`;`).\n+\tDefault: '%Ggitcvs.%m.sqlite'\n+\n gitcvs.dbuser, gitcvs.dbpass::\n \tDatabase user and password. Only useful if setting 'gitcvs.dbdriver',\n \tsince SQLite has no concept of database users and/or passwords.\n@@ -1068,19 +1050,49 @@ gitcvs.dbTableNamePrefix::\n \tDatabase table name prefix.  Prepended to the names of any\n \tdatabase tables used, allowing a single database to be used\n \tfor several repositories.  Supports variable substitution (see\n-\tlinkgit:git-cvsserver[1] for details).  Any non-alphabetic\n+\tlinkgit:git-cvsserver[1] for details).\tAny non-alphabetic\n \tcharacters will be replaced with underscores.\n \n+gitcvs.enabled::\n+\tWhether the CVS server interface is enabled for this repository.\n+\tSee linkgit:git-cvsserver[1].\n+\n+gitcvs.logfile::\n+\tPath to a log file where the CVS server interface well... logs\n+\tvarious stuff. See linkgit:git-cvsserver[1].\n+\n+gitcvs.usecrlfattr::\n+\tIf true, the server will look up the end-of-line conversion\n+\tattributes for files to determine the '-k' modes to use. If\n+\tthe attributes force git to treat a file as text,\n+\tthe '-k' mode will be left blank so CVS clients will\n+\ttreat it as text. If they suppress text conversion, the file\n+\twill be set with '-kb' mode, which suppresses any newline munging\n+\tthe client might otherwise do. If the attributes do not allow\n+\tthe file type to be determined, then 'gitcvs.allbinary' is\n+\tused. See linkgit:gitattributes[5].\n+\n All gitcvs variables except for 'gitcvs.usecrlfattr' and\n 'gitcvs.allbinary' can also be specified as\n 'gitcvs.<access_method>.<varname>' (where 'access_method'\n is one of \"ext\" and \"pserver\") to make them apply only for the given\n access method.\n \n+gui.blamehistoryctx::\n+\tSpecifies the radius of history context in days to show in\n+\tlinkgit:gitk[1] for the selected commit, when the `Show History\n+\tContext` menu item is invoked from 'git gui blame'. If this\n+\tvariable is set to zero, the whole history is shown.\n+\n gui.commitmsgwidth::\n \tDefines how wide the commit message window is in the\n \tlinkgit:git-gui[1]. \"75\" is the default.\n \n+gui.copyblamethreshold::\n+\tSpecifies the threshold to use in 'git gui blame' original location\n+\tdetection, measured in alphanumeric characters. See the\n+\tlinkgit:git-blame[1] manual for more information on copy detection.\n+\n gui.diffcontext::\n \tSpecifies how many context lines should be used in calls to diff\n \tmade by the linkgit:git-gui[1]. The default is \"5\".\n@@ -1093,6 +1105,11 @@ gui.encoding::\n \tIf this option is not set, the tools default to the\n \tlocale encoding.\n \n+gui.fastcopyblame::\n+\tIf true, 'git gui blame' uses `-C` instead of `-C -C` for original\n+\tlocation detection. It makes blame significantly faster on huge\n+\trepositories at the expense of less thorough copy detection.\n+\n gui.matchtrackingbranch::\n \tDetermines if new branches created with linkgit:git-gui[1] should\n \tdefault to tracking remote branches with matching names or\n@@ -1106,30 +1123,22 @@ gui.pruneduringfetch::\n \t\"true\" if linkgit:git-gui[1] should prune remote-tracking branches when\n \tperforming a fetch. The default value is \"false\".\n \n-gui.trustmtime::\n-\tDetermines if linkgit:git-gui[1] should trust the file modification\n-\ttimestamp or not. By default the timestamps are not trusted.\n-\n gui.spellingdictionary::\n \tSpecifies the dictionary used for spell checking commit messages in\n \tthe linkgit:git-gui[1]. When set to \"none\" spell checking is turned\n \toff.\n \n-gui.fastcopyblame::\n-\tIf true, 'git gui blame' uses `-C` instead of `-C -C` for original\n-\tlocation detection. It makes blame significantly faster on huge\n-\trepositories at the expense of less thorough copy detection.\n-\n-gui.copyblamethreshold::\n-\tSpecifies the threshold to use in 'git gui blame' original location\n-\tdetection, measured in alphanumeric characters. See the\n-\tlinkgit:git-blame[1] manual for more information on copy detection.\n+gui.trustmtime::\n+\tDetermines if linkgit:git-gui[1] should trust the file modification\n+\ttimestamp or not. By default the timestamps are not trusted.\n \n-gui.blamehistoryctx::\n-\tSpecifies the radius of history context in days to show in\n-\tlinkgit:gitk[1] for the selected commit, when the `Show History\n-\tContext` menu item is invoked from 'git gui blame'. If this\n-\tvariable is set to zero, the whole history is shown.\n+guitool.<name>.argprompt::\n+\tRequest a string argument from the user, and pass it to the tool\n+\tthrough the 'ARGS' environment variable. Since requesting an\n+\targument implies confirmation, the 'confirm' option has no effect\n+\tif this is enabled. If the option is set to 'true', 'yes', or '1',\n+\tthe dialog uses a built-in generic prompt; otherwise the exact\n+\tvalue of the variable is used.\n \n guitool.<name>.cmd::\n \tSpecifies the shell command line to execute when the corresponding item\n@@ -1140,6 +1149,9 @@ guitool.<name>.cmd::\n \t'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if\n \tthe head is detached, 'CUR_BRANCH' is empty).\n \n+guitool.<name>.confirm::\n+\tShow a confirmation dialog before actually running the tool.\n+\n guitool.<name>.needsfile::\n \tRun the tool only if a diff is selected in the GUI. It guarantees\n \tthat 'FILENAME' is not empty.\n@@ -1152,16 +1164,10 @@ guitool.<name>.norescan::\n \tDon't rescan the working directory for changes after the tool\n \tfinishes execution.\n \n-guitool.<name>.confirm::\n-\tShow a confirmation dialog before actually running the tool.\n-\n-guitool.<name>.argprompt::\n-\tRequest a string argument from the user, and pass it to the tool\n-\tthrough the 'ARGS' environment variable. Since requesting an\n-\targument implies confirmation, the 'confirm' option has no effect\n-\tif this is enabled. If the option is set to 'true', 'yes', or '1',\n-\tthe dialog uses a built-in generic prompt; otherwise the exact\n-\tvalue of the variable is used.\n+guitool.<name>.prompt::\n+\tSpecifies the general prompt string to display at the top of\n+\tthe dialog, before subsections for 'argprompt' and 'revprompt'.\n+\tThe default value includes the actual command.\n \n guitool.<name>.revprompt::\n \tRequest a single valid revision from the user, and set the\n@@ -1177,20 +1183,6 @@ guitool.<name>.title::\n \tSpecifies the title to use for the prompt dialog. The default\n \tis the tool name.\n \n-guitool.<name>.prompt::\n-\tSpecifies the general prompt string to display at the top of\n-\tthe dialog, before subsections for 'argprompt' and 'revprompt'.\n-\tThe default value includes the actual command.\n-\n-help.browser::\n-\tSpecify the browser that will be used to display help in the\n-\t'web' format. See linkgit:git-help[1].\n-\n-help.format::\n-\tOverride the default help format used by linkgit:git-help[1].\n-\tValues 'man', 'info', 'web' and 'html' are supported. 'man' is\n-\tthe default. 'web' and 'html' are the same.\n-\n help.autocorrect::\n \tAutomatically correct and execute mistyped commands after\n \twaiting for the given number of deciseconds (0.1 sec). If more\n@@ -1200,41 +1192,20 @@ help.autocorrect::\n \tvalue is 0 - the command will be just shown but not executed.\n \tThis is the default.\n \n-http.proxy::\n-\tOverride the HTTP proxy, normally configured using the 'http_proxy'\n-\tenvironment variable (see linkgit:curl[1]).  This can be overridden\n-\ton a per-remote basis; see remote.<name>.proxy\n-\n-http.sslVerify::\n-\tWhether to verify the SSL certificate when fetching or pushing\n-\tover HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment\n-\tvariable.\n-\n-http.sslCert::\n-\tFile containing the SSL certificate when fetching or pushing\n-\tover HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment\n-\tvariable.\n-\n-http.sslKey::\n-\tFile containing the SSL private key when fetching or pushing\n-\tover HTTPS. Can be overridden by the 'GIT_SSL_KEY' environment\n-\tvariable.\n-\n-http.sslCertPasswordProtected::\n-\tEnable git's password prompt for the SSL certificate.  Otherwise\n-\tOpenSSL will prompt the user, possibly many times, if the\n-\tcertificate or private key is encrypted.  Can be overridden by the\n-\t'GIT_SSL_CERT_PASSWORD_PROTECTED' environment variable.\n-\n-http.sslCAInfo::\n-\tFile containing the certificates to verify the peer with when\n-\tfetching or pushing over HTTPS. Can be overridden by the\n-\t'GIT_SSL_CAINFO' environment variable.\n+help.browser::\n+\tSpecify the browser that will be used to display help in the\n+\t'web' format. See linkgit:git-help[1].\n \n-http.sslCAPath::\n-\tPath containing files with the CA certificates to verify the peer\n-\twith when fetching or pushing over HTTPS. Can be overridden\n-\tby the 'GIT_SSL_CAPATH' environment variable.\n+help.format::\n+\tOverride the default help format used by linkgit:git-help[1].\n+\tValues 'man', 'info', 'web' and 'html' are supported. 'man' is\n+\tthe default. 'web' and 'html' are the same.\n+\n+http.lowSpeedLimit, http.lowSpeedTime::\n+\tIf the HTTP transfer speed is less than 'http.lowSpeedLimit'\n+\tfor longer than 'http.lowSpeedTime' seconds, the transfer is aborted.\n+\tCan be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and\n+\t'GIT_HTTP_LOW_SPEED_TIME' environment variables.\n \n http.maxRequests::\n \tHow many HTTP requests to launch in parallel. Can be overridden\n@@ -1246,6 +1217,12 @@ http.minSessions::\n \thttp_cleanup() is invoked. If USE_CURL_MULTI is not defined, this\n \tvalue will be capped at 1. Defaults to 1.\n \n+http.noEPSV::\n+\tA boolean which disables using of EPSV ftp command by curl.\n+\tThis can helpful with some \"poor\" ftp servers which don't\n+\tsupport EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'\n+\tenvironment variable. Default is false (curl will use EPSV).\n+\n http.postBuffer::\n \tMaximum size in bytes of the buffer used by smart HTTP\n \ttransports when POSTing data to the remote system.\n@@ -1254,20 +1231,44 @@ http.postBuffer::\n \tmassive pack file locally.  Default is 1 MiB, which is\n \tsufficient for most requests.\n \n-http.lowSpeedLimit, http.lowSpeedTime::\n-\tIf the HTTP transfer speed is less than 'http.lowSpeedLimit'\n-\tfor longer than 'http.lowSpeedTime' seconds, the transfer is aborted.\n-\tCan be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and\n-\t'GIT_HTTP_LOW_SPEED_TIME' environment variables.\n+http.proxy::\n+\tOverride the HTTP proxy, normally configured using the 'http_proxy'\n+\tenvironment variable (see linkgit:curl[1]).  This can be overridden\n+\ton a per-remote basis; see remote.<name>.proxy\n \n-http.noEPSV::\n-\tA boolean which disables using of EPSV ftp command by curl.\n-\tThis can helpful with some \"poor\" ftp servers which don't\n-\tsupport EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'\n-\tenvironment variable. Default is false (curl will use EPSV).\n+http.sslCAInfo::\n+\tFile containing the certificates to verify the peer with when\n+\tfetching or pushing over HTTPS. Can be overridden by the\n+\t'GIT_SSL_CAINFO' environment variable.\n+\n+http.sslCAPath::\n+\tPath containing files with the CA certificates to verify the peer\n+\twith when fetching or pushing over HTTPS. Can be overridden\n+\tby the 'GIT_SSL_CAPATH' environment variable.\n+\n+http.sslCert::\n+\tFile containing the SSL certificate when fetching or pushing\n+\tover HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment\n+\tvariable.\n+\n+http.sslCertPasswordProtected::\n+\tEnable git's password prompt for the SSL certificate.  Otherwise\n+\tOpenSSL will prompt the user, possibly many times, if the\n+\tcertificate or private key is encrypted.  Can be overridden by the\n+\t'GIT_SSL_CERT_PASSWORD_PROTECTED' environment variable.\n+\n+http.sslKey::\n+\tFile containing the SSL private key when fetching or pushing\n+\tover HTTPS. Can be overridden by the 'GIT_SSL_KEY' environment\n+\tvariable.\n+\n+http.sslVerify::\n+\tWhether to verify the SSL certificate when fetching or pushing\n+\tover HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment\n+\tvariable.\n \n http.useragent::\n-\tThe HTTP USER_AGENT string presented to an HTTP server.  The default\n+\tThe HTTP USER_AGENT string presented to an HTTP server.\t The default\n \tvalue represents the version of the client git such as git/1.7.1.\n \tThis option allows you to override this value to a more common value\n \tsuch as Mozilla/4.0.  This may be necessary, for instance, if\n@@ -1350,10 +1351,6 @@ mailmap.file::\n \tsubdirectory, or somewhere outside of the repository itself.\n \tSee linkgit:git-shortlog[1] and linkgit:git-blame[1].\n \n-man.viewer::\n-\tSpecify the programs that may be used to display help in the\n-\t'man' format. See linkgit:git-help[1].\n-\n man.<tool>.cmd::\n \tSpecify the command to invoke the specified man viewer. The\n \tspecified command is evaluated in shell with the man page\n@@ -1363,14 +1360,14 @@ man.<tool>.path::\n \tOverride the path for the given tool that may be used to\n \tdisplay help in the 'man' format. See linkgit:git-help[1].\n \n-include::merge-config.txt[]\n+man.viewer::\n+\tSpecify the programs that may be used to display help in the\n+\t'man' format. See linkgit:git-help[1].\n \n-mergetool.<tool>.path::\n-\tOverride the path for the given tool.  This is useful in case\n-\tyour tool is not in the PATH.\n+include::merge-config.txt[]\n \n mergetool.<tool>.cmd::\n-\tSpecify the command to invoke the specified merge tool.  The\n+\tSpecify the command to invoke the specified merge tool.\t The\n \tspecified command is evaluated in shell with the following\n \tvariables available: 'BASE' is the name of a temporary file\n \tcontaining the common base of the files to be merged, if available;\n@@ -1380,6 +1377,10 @@ mergetool.<tool>.cmd::\n \tmerged; 'MERGED' contains the name of the file to which the merge\n \ttool should write the results of a successful merge.\n \n+mergetool.<tool>.path::\n+\tOverride the path for the given tool.  This is useful in case\n+\tyour tool is not in the PATH.\n+\n mergetool.<tool>.trustExitCode::\n \tFor a custom merge command, specify whether the exit code of\n \tthe merge command can be used to determine whether the merge was\n@@ -1408,8 +1409,8 @@ notes.displayRef::\n \tThe (fully qualified) refname from which to show notes when\n \tshowing commit messages.  The value of this variable can be set\n \tto a glob, in which case notes from all matching refs will be\n-\tshown.  You may also specify this configuration variable\n-\tseveral times.  A warning will be issued for refs that do not\n+\tshown.\tYou may also specify this configuration variable\n+\tseveral times.\tA warning will be issued for refs that do not\n \texist, but a glob that does not match any refs is silently\n \tignored.\n +\n@@ -1451,20 +1452,6 @@ This setting can be overridden with the `GIT_NOTES_REWRITE_REF`\n environment variable, which must be a colon separated list of refs or\n globs.\n \n-pack.window::\n-\tThe size of the window used by linkgit:git-pack-objects[1] when no\n-\twindow size is given on the command line. Defaults to 10.\n-\n-pack.depth::\n-\tThe maximum delta depth used by linkgit:git-pack-objects[1] when no\n-\tmaximum depth is given on the command line. Defaults to 50.\n-\n-pack.windowMemory::\n-\tThe window memory size limit used by linkgit:git-pack-objects[1]\n-\twhen no limit is given on the command line.  The value can be\n-\tsuffixed with \"k\", \"m\", or \"g\".  Defaults to 0, meaning no\n-\tlimit.\n-\n pack.compression::\n \tAn integer -1..9, indicating the compression level for objects\n \tin a pack file. -1 is the zlib default. 0 means no\n@@ -1478,6 +1465,12 @@ Note that changing the compression level will not automatically recompress\n all existing objects. You can force recompression by passing the -F option\n to linkgit:git-repack[1].\n \n+pack.deltaCacheLimit::\n+\tThe maximum size of a delta, that is cached in\n+\tlinkgit:git-pack-objects[1]. This cache is used to speed up the\n+\twriting object phase by not having to recompute the final delta\n+\tresult once the best match for all objects is found. Defaults to 1000.\n+\n pack.deltaCacheSize::\n \tThe maximum memory in bytes used for caching deltas in\n \tlinkgit:git-pack-objects[1] before writing them out to a pack.\n@@ -1489,28 +1482,16 @@ pack.deltaCacheSize::\n \tA value of 0 means no limit. The smallest size of 1 byte may be\n \tused to virtually disable this cache. Defaults to 256 MiB.\n \n-pack.deltaCacheLimit::\n-\tThe maximum size of a delta, that is cached in\n-\tlinkgit:git-pack-objects[1]. This cache is used to speed up the\n-\twriting object phase by not having to recompute the final delta\n-\tresult once the best match for all objects is found. Defaults to 1000.\n-\n-pack.threads::\n-\tSpecifies the number of threads to spawn when searching for best\n-\tdelta matches.  This requires that linkgit:git-pack-objects[1]\n-\tbe compiled with pthreads otherwise this option is ignored with a\n-\twarning. This is meant to reduce packing time on multiprocessor\n-\tmachines. The required amount of memory for the delta search window\n-\tis however multiplied by the number of threads.\n-\tSpecifying 0 will cause git to auto-detect the number of CPU's\n-\tand set the number of threads accordingly.\n+pack.depth::\n+\tThe maximum delta depth used by linkgit:git-pack-objects[1] when no\n+\tmaximum depth is given on the command line. Defaults to 50.\n \n pack.indexVersion::\n-\tSpecify the default pack index version.  Valid values are 1 for\n+\tSpecify the default pack index version.\t Valid values are 1 for\n \tlegacy pack index used by Git versions prior to 1.5.2, and 2 for\n \tthe new pack index with capabilities for packs larger than 4 GB\n \tas well as proper protection against the repacking of corrupted\n-\tpacks.  Version 2 is the default.  Note that version 2 is enforced\n+\tpacks.\tVersion 2 is the default.  Note that version 2 is enforced\n \tand this config option ignored whenever the corresponding pack is\n \tlarger than 2 GB.\n +\n@@ -1525,12 +1506,32 @@ the `{asterisk}.idx` file.\n pack.packSizeLimit::\n \tThe maximum size of a pack.  This setting only affects\n \tpacking to a file when repacking, i.e. the git:// protocol\n-\tis unaffected.  It can be overridden by the `\\--max-pack-size`\n+\tis unaffected.\tIt can be overridden by the `\\--max-pack-size`\n \toption of linkgit:git-repack[1]. The minimum size allowed is\n \tlimited to 1 MiB. The default is unlimited.\n \tCommon unit suffixes of 'k', 'm', or 'g' are\n \tsupported.\n \n+pack.threads::\n+\tSpecifies the number of threads to spawn when searching for best\n+\tdelta matches.\tThis requires that linkgit:git-pack-objects[1]\n+\tbe compiled with pthreads otherwise this option is ignored with a\n+\twarning. This is meant to reduce packing time on multiprocessor\n+\tmachines. The required amount of memory for the delta search window\n+\tis however multiplied by the number of threads.\n+\tSpecifying 0 will cause git to auto-detect the number of CPU's\n+\tand set the number of threads accordingly.\n+\n+pack.window::\n+\tThe size of the window used by linkgit:git-pack-objects[1] when no\n+\twindow size is given on the command line. Defaults to 10.\n+\n+pack.windowMemory::\n+\tThe window memory size limit used by linkgit:git-pack-objects[1]\n+\twhen no limit is given on the command line.  The value can be\n+\tsuffixed with \"k\", \"m\", or \"g\".\t Defaults to 0, meaning no\n+\tlimit.\n+\n pager.<cmd>::\n \tAllows turning on or off pagination of the output of a\n \tparticular git subcommand when writing to a tty.  If\n@@ -1568,42 +1569,18 @@ push.default::\n * `tracking` - push the current branch to its upstream branch.\n * `current` - push the current branch to a branch of the same name.\n \n+rebase.autosquash::\n+\tIf set to true enable '--autosquash' option by default.\n+\n rebase.stat::\n \tWhether to show a diffstat of what changed upstream since the last\n \trebase. False by default.\n \n-rebase.autosquash::\n-\tIf set to true enable '--autosquash' option by default.\n-\n receive.autogc::\n \tBy default, git-receive-pack will run \"git-gc --auto\" after\n-\treceiving data from git-push and updating refs.  You can stop\n+\treceiving data from git-push and updating refs.\t You can stop\n \tit by setting this variable to false.\n \n-receive.fsckObjects::\n-\tIf it is set to true, git-receive-pack will check all received\n-\tobjects. It will abort in the case of a malformed object or a\n-\tbroken link. The result of an abort are only dangling objects.\n-\tDefaults to false.\n-\n-receive.unpackLimit::\n-\tIf the number of objects received in a push is below this\n-\tlimit then the objects will be unpacked into loose object\n-\tfiles. However if the number of received objects equals or\n-\texceeds this limit then the received pack will be stored as\n-\ta pack, after adding any missing delta bases.  Storing the\n-\tpack from a push can make the push operation complete faster,\n-\tespecially on slow filesystems.  If not set, the value of\n-\t`transfer.unpackLimit` is used instead.\n-\n-receive.denyDeletes::\n-\tIf set to true, git-receive-pack will deny a ref update that deletes\n-\tthe ref. Use this to prevent such a ref deletion via a push.\n-\n-receive.denyDeleteCurrent::\n-\tIf set to true, git-receive-pack will deny a ref update that\n-\tdeletes the currently checked out branch of a non-bare repository.\n-\n receive.denyCurrentBranch::\n \tIf set to true or \"refuse\", git-receive-pack will deny a ref update\n \tto the currently checked out branch of a non-bare repository.\n@@ -1613,39 +1590,63 @@ receive.denyCurrentBranch::\n \tproceed. If set to false or \"ignore\", allow such pushes with no\n \tmessage. Defaults to \"refuse\".\n \n+receive.denyDeletes::\n+\tIf set to true, git-receive-pack will deny a ref update that deletes\n+\tthe ref. Use this to prevent such a ref deletion via a push.\n+\n+receive.denyDeleteCurrent::\n+\tIf set to true, git-receive-pack will deny a ref update that\n+\tdeletes the currently checked out branch of a non-bare repository.\n+\n receive.denyNonFastForwards::\n \tIf set to true, git-receive-pack will deny a ref update which is\n \tnot a fast-forward. Use this to prevent such an update via a push,\n \teven if that push is forced. This configuration variable is\n \tset when initializing a shared repository.\n \n+receive.fsckObjects::\n+\tIf it is set to true, git-receive-pack will check all received\n+\tobjects. It will abort in the case of a malformed object or a\n+\tbroken link. The result of an abort are only dangling objects.\n+\tDefaults to false.\n+\n+receive.unpackLimit::\n+\tIf the number of objects received in a push is below this\n+\tlimit then the objects will be unpacked into loose object\n+\tfiles. However if the number of received objects equals or\n+\texceeds this limit then the received pack will be stored as\n+\ta pack, after adding any missing delta bases.  Storing the\n+\tpack from a push can make the push operation complete faster,\n+\tespecially on slow filesystems.\t If not set, the value of\n+\t`transfer.unpackLimit` is used instead.\n+\n receive.updateserverinfo::\n \tIf set to true, git-receive-pack will run git-update-server-info\n \tafter receiving data from git-push and updating refs.\n \n-remote.<name>.url::\n-\tThe URL of a remote repository.  See linkgit:git-fetch[1] or\n-\tlinkgit:git-push[1].\n+remote.<name>.fetch::\n+\tThe default set of \"refspec\" for linkgit:git-fetch[1]. See\n+\tlinkgit:git-fetch[1].\n \n-remote.<name>.pushurl::\n-\tThe push URL of a remote repository.  See linkgit:git-push[1].\n+remote.<name>.mirror::\n+\tIf true, pushing to this remote will automatically behave\n+\tas if the `\\--mirror` option was given on the command line.\n \n remote.<name>.proxy::\n \tFor remotes that require curl (http, https and ftp), the URL to\n \tthe proxy to use for that remote.  Set to the empty string to\n \tdisable proxying for that remote.\n \n-remote.<name>.fetch::\n-\tThe default set of \"refspec\" for linkgit:git-fetch[1]. See\n-\tlinkgit:git-fetch[1].\n-\n remote.<name>.push::\n \tThe default set of \"refspec\" for linkgit:git-push[1]. See\n \tlinkgit:git-push[1].\n \n-remote.<name>.mirror::\n-\tIf true, pushing to this remote will automatically behave\n-\tas if the `\\--mirror` option was given on the command line.\n+remote.<name>.pushurl::\n+\tThe push URL of a remote repository.  See linkgit:git-push[1].\n+\n+remote.<name>.receivepack::\n+\tThe default program to execute on the remote side when pushing.\t See\n+\toption \\--receive-pack of linkgit:git-push[1].\n \n remote.<name>.skipDefaultUpdate::\n \tIf true, this remote will be skipped by default when updating\n@@ -1657,14 +1658,6 @@ remote.<name>.skipFetchAll::\n \tusing linkgit:git-fetch[1] or the `update` subcommand of\n \tlinkgit:git-remote[1].\n \n-remote.<name>.receivepack::\n-\tThe default program to execute on the remote side when pushing.  See\n-\toption \\--receive-pack of linkgit:git-push[1].\n-\n-remote.<name>.uploadpack::\n-\tThe default program to execute on the remote side when fetching.  See\n-\toption \\--upload-pack of linkgit:git-fetch-pack[1].\n-\n remote.<name>.tagopt::\n \tSetting this value to \\--no-tags disables automatic tag following when\n \tfetching from remote <name>. Setting it to \\--tags will fetch every\n@@ -1673,6 +1666,14 @@ remote.<name>.tagopt::\n \toverride this setting. See options \\--tags and \\--no-tags of\n \tlinkgit:git-fetch[1].\n \n+remote.<name>.uploadpack::\n+\tThe default program to execute on the remote side when fetching.  See\n+\toption \\--upload-pack of linkgit:git-fetch-pack[1].\n+\n+remote.<name>.url::\n+\tThe URL of a remote repository.\t See linkgit:git-fetch[1] or\n+\tlinkgit:git-push[1].\n+\n remote.<name>.vcs::\n \tSetting this to a value <vcs> will cause git to interact with\n \tthe remote with the git-remote-<vcs> helper.\n@@ -1692,7 +1693,7 @@ repack.usedeltabaseoffset::\n rerere.autoupdate::\n \tWhen set to true, `git-rerere` updates the index with the\n \tresulting contents after it cleanly resolves conflicts using\n-\tpreviously recorded resolution.  Defaults to false.\n+\tpreviously recorded resolution.\t Defaults to false.\n \n rerere.enabled::\n \tActivate recording of resolved conflicts, so that identical\n@@ -1701,25 +1702,6 @@ rerere.enabled::\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 \n-sendemail.identity::\n-\tA configuration identity. When given, causes values in the\n-\t'sendemail.<identity>' subsection to take precedence over\n-\tvalues in the 'sendemail' section. The default identity is\n-\tthe value of 'sendemail.identity'.\n-\n-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-\tDeprecated alias for 'sendemail.smtpencryption = ssl'.\n-\n-sendemail.<identity>.*::\n-\tIdentity-specific versions of the 'sendemail.*' parameters\n-\tfound below, taking precedence over those when the this\n-\tidentity is selected, through command-line or\n-\t'sendemail.identity'.\n-\n sendemail.aliasesfile::\n sendemail.aliasfiletype::\n sendemail.bcc::\n@@ -1744,9 +1726,28 @@ sendemail.thread::\n sendemail.validate::\n \tSee linkgit:git-send-email[1] for description.\n \n+sendemail.identity::\n+\tA configuration identity. When given, causes values in the\n+\t'sendemail.<identity>' subsection to take precedence over\n+\tvalues in the 'sendemail' section. The default identity is\n+\tthe value of 'sendemail.identity'.\n+\n sendemail.signedoffcc::\n \tDeprecated alias for 'sendemail.signedoffbycc'.\n \n+sendemail.smtpencryption::\n+\tSee linkgit:git-send-email[1] for description.\tNote that this\n+\tsetting is not subject to the 'identity' mechanism.\n+\n+sendemail.smtpssl::\n+\tDeprecated alias for 'sendemail.smtpencryption = ssl'.\n+\n+sendemail.<identity>.*::\n+\tIdentity-specific versions of the 'sendemail.*' parameters\n+\tfound below, taking precedence over those when the this\n+\tidentity is selected, through command-line or\n+\t'sendemail.identity'.\n+\n showbranch.default::\n \tThe default set of branches for linkgit:git-show-branch[1].\n \tSee linkgit:git-show-branch[1].\n@@ -1784,13 +1785,18 @@ status.submodulesummary::\n \t--summary-limit option of linkgit:git-submodule[1]).\n \n submodule.<name>.path::\n-submodule.<name>.url::\n+\tThe path within this project, URL.  The variable is initially populated\n+\tby 'git submodule init'; edit to override.\n+\n submodule.<name>.update::\n-\tThe path within this project, URL, and the updating strategy\n-\tfor a submodule.  These variables are initially populated\n-\tby 'git submodule init'; edit them to override the\n-\tURL and other values found in the `.gitmodules` file.  See\n-\tlinkgit:git-submodule[1] and linkgit:gitmodules[5] for details.\n+\tUupdating strategy for a submodule.  The variable is initially\n+\tpopulated by 'git submodule init'; edit to override values\n+\tfound in the `.gitmodules` file.  See linkgit:git-submodule[1]\n+\tand linkgit:gitmodules[5] for details.\n+\n+submodule.<name>.url::\n+\tThe project URL.  The variable is initially populated by 'git\n+\tsubmodule init'; edit to override.\n \n submodule.<name>.ignore::\n \tDefines under what circumstances \"git status\" and the diff family show\n@@ -1844,12 +1850,12 @@ url.<base>.pushInsteadOf::\n user.email::\n \tYour email address to be recorded in any newly created commits.\n \tCan be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and\n-\t'EMAIL' environment variables.  See linkgit:git-commit-tree[1].\n+\t'EMAIL' environment variables.\tSee linkgit:git-commit-tree[1].\n \n user.name::\n \tYour full name to be recorded in any newly created commits.\n \tCan be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'\n-\tenvironment variables.  See linkgit:git-commit-tree[1].\n+\tenvironment variables.\tSee linkgit:git-commit-tree[1].\n \n user.signingkey::\n \tIf linkgit:git-tag[1] is not selecting the key you want it to\n-- \n1.7.2.3\n"},{"id":"156927","messageId":"m3eia14mu7.fsf@localhost.localdomain","threadId":"25878","inReplyTo":"1291209174-9239-1-git-send-email-jari.aalto@cante.net","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-01T13:58:45Z","receivedAt":"2010-12-01T13:58:45Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"jari.aalto@cante.net writes:\n\n> From: Jari Aalto <jari.aalto@cante.net>\n> \n> \n> Signed-off-by: Jari Aalto <jari.aalto@cante.net>\n> ---\n>  Documentation/config.txt | 1698 +++++++++++++++++++++++-----------------------\n>  1 files changed, 852 insertions(+), 846 deletions(-)\n\nWhy?  What such large change is for?\n\nNote that currently config variables are grouped by functionality: for\nexample core.eol and core.safecrlf, or core.compression and\ncore.loosecompression are close to each other.\n\nI like the fact that we have first advice.*, then core.*, then mostly\nalphabetically sorted rest of configuration variables.\n\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 6a6c0b5..6e92623 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -142,313 +142,251 @@ advice.*::\n>  \tdetachedHead::\n>  \t\tAdvice shown when you used linkgit::git-checkout[1] to\n>  \t\tmove to the detach HEAD state, to instruct how to create\n> -\t\ta local branch after the fact.  Default: true.\n> +\t\ta local branch after the fact.\tDefault: true.\n\nThis change has nothing to do with ordering variables alphabetically,\ntherefore IMHO it belongs in separate patch.\n\n[...]\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"156931","messageId":"20101201143436.GC6537@picasso.cante.net","threadId":"25878","inReplyTo":"m3eia14mu7.fsf@localhost.localdomain","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"jari","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T14:34:36Z","receivedAt":"2010-12-01T14:34:36Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"On 2010-12-01 05:58, Jakub Narebski wrote:\n| >  \t\tAdvice shown when you used linkgit::git-checkout[1] to\n| >  \t\tmove to the detach HEAD state, to instruct how to create\n| > -\t\ta local branch after the fact.  Default: true.\n| > +\t\ta local branch after the fact.\tDefault: true.\n| \n| This change has nothing to do with ordering variables alphabetically,\n| therefore IMHO it belongs in separate patch.\n\nHm, I tabified the content, so it chnaged inserted \" \" to \"^I\". Fix\nwill follow.\n\nJari\n"},{"id":"156934","messageId":"201012011557.30849.jnareb@gmail.com","threadId":"25878","inReplyTo":"20101201142920.GB6537@picasso.cante.net","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-01T14:57:29Z","receivedAt":"2010-12-01T14:57:29Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 1 Dec 2010, Jari Aalto wrote:\n> On 2010-12-01 05:58, Jakub Narebski wrote:\n> | jari.aalto@cante.net writes:\n> | \n> | > From: Jari Aalto <jari.aalto@cante.net>\n> | > \n> | > \n> | > Signed-off-by: Jari Aalto <jari.aalto@cante.net>\n> | > ---\n> | >  Documentation/config.txt | 1698 +++++++++++++++++++++++-----------------------\n> | >  1 files changed, 852 insertions(+), 846 deletions(-)\n> | \n> | Why?  What such large change is for?\n> | \n> | Note that currently config variables are grouped by functionality: for\n> | example core.eol and core.safecrlf, or core.compression and\n> | core.loosecompression are close to each other.\n\nWhat about the above?\n \n> The phone books have an index where to up information.\n> \n>     - When you see script and it use VARIABLE, you look it from\n>       manual page\n\nManpages (and 'git <cmd> --help') are displayed in pager, so you can\nalways search for option in a pager (e.g. '/' in 'less', the default\npager).\n\n> \n> It is same as putting option in alphabetical order. See GNU cp(1),\n> ssh(1) etc.\n\nIn git documentation command line options are not in alphabetical order,\nbut grouped by functionality, therefore your argument is invalid.\n\nSee also GNU tar(1), rpm(8), uname(1) from coreutils, etc.\n\n> \n> There are zillion values and for a reference, alphabetical order makes\n> sense.\n\nI agree that alphabetical order makes sense for glossary; I disagree that\nit makes sense here.\n\n\nSidenote: we can always sort variables alphabetically using a script, but\nreverse operation cannot be automated.\n-- \nJakub Narebski\nPoland\n"},{"id":"156939","messageId":"20101201150917.GD6537@picasso.cante.net","threadId":"25878","inReplyTo":"201012011557.30849.jnareb@gmail.com","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"jari","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T15:09:17Z","receivedAt":"2010-12-01T15:09:17Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"On 2010-12-01 15:57, Jakub Narebski wrote:\n| On Wed, 1 Dec 2010, Jari Aalto wrote:\n| > On 2010-12-01 05:58, Jakub Narebski wrote:\n| > | jari.aalto@cante.net writes:\n| > | \n| > | > From: Jari Aalto <jari.aalto@cante.net>\n| > | > \n| > | > \n| > | > Signed-off-by: Jari Aalto <jari.aalto@cante.net>\n| > | > ---\n| > | >  Documentation/config.txt | 1698 +++++++++++++++++++++++-----------------------\n| > | >  1 files changed, 852 insertions(+), 846 deletions(-)\n| > | \n| > | Why?  What such large change is for?\n| > | \n| > | Note that currently config variables are grouped by functionality: for\n| > | example core.eol and core.safecrlf, or core.compression and\n| > | core.loosecompression are close to each other.\n| \n| What about the above?\n\nWe use standard biblical refences:\n\n\t Se ....\n\nSuggest what is needed, and it will be so.\n\n| > The phone books have an index where to up information.\n| > \n| >     - When you see script and it use VARIABLE, you look it from\n| >       manual page\n| \n| Manpages (and 'git <cmd> --help') are displayed in pager, so you can\n| always search for option in a pager (e.g. '/' in 'less', the default\n| pager).\n\nYuck, it's real fun start backward/forward ping-pong when you dont'\nknow the directions and can't rely on standard A-Z index.\n\n| > It is same as putting option in alphabetical order. See GNU cp(1),\n| > ssh(1) etc.\n| \n| In git documentation command line options are not in alphabetical order,\n| but grouped by functionality, therefore your argument is invalid.\n\nI see that only in pages that have tens and tens and tens of options..\n\nThe problem is more the asciidoc's. Various bits and pices are\n\"included\" in place and make orderign the options impossile in some\npages.\n\nLet's get all pages in shape with A-Z in this regard. That's a god\nquality goal.\n\n| > There are zillion values and for a reference, alphabetical order makes\n| > sense.\n| \n| I agree that alphabetical order makes sense for glossary; I disagree that\n| it makes sense here.\n\nAbout 60% in git-config is already in alpha order (core.*, sendmail.*\netc), so there is not really much that is changing.\n\nWell. If standard reading order is not the standard, I don't know what\nis.\n\nJari\n"},{"id":"156940","messageId":"AANLkTindMBh4dzo-VG2vPrKfgNZVUhs0-5AEU2fWChaC@mail.gmail.com","threadId":"25878","inReplyTo":"20101201150917.GD6537@picasso.cante.net","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2010-12-01T15:19:16Z","receivedAt":"2010-12-01T15:19:16Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Dec 1, 2010 at 4:09 PM, jari <jari.aalto@cante.net> wrote:\n> On 2010-12-01 15:57, Jakub Narebski wrote:\n> | On Wed, 1 Dec 2010, Jari Aalto wrote:\n> | > The phone books have an index where to up information.\n> | >\n> | >     - When you see script and it use VARIABLE, you look it from\n> | >       manual page\n> |\n> | Manpages (and 'git <cmd> --help') are displayed in pager, so you can\n> | always search for option in a pager (e.g. '/' in 'less', the default\n> | pager).\n>\n> Yuck, it's real fun start backward/forward ping-pong when you dont'\n> know the directions and can't rely on standard A-Z index.\n>\n\n...but for config options, I tend to ping-pong between items that are\nrelated to each other, which are already located close by. Your\nargument weighs more for keeping the current layout, IMO.\n\n> | > It is same as putting option in alphabetical order. See GNU cp(1),\n> | > ssh(1) etc.\n> |\n> | In git documentation command line options are not in alphabetical order,\n> | but grouped by functionality, therefore your argument is invalid.\n>\n> I see that only in pages that have tens and tens and tens of options..\n>\n> The problem is more the asciidoc's. Various bits and pices are\n> \"included\" in place and make orderign the options impossile in some\n> pages.\n>\n> Let's get all pages in shape with A-Z in this regard. That's a god\n> quality goal.\n>\n\nI still haven't heard a compelling argument why alphabetical ordering\nis better than logical ordering...\n"},{"id":"156942","messageId":"877hftwlqz.fsf@picasso.cante.net","threadId":"25878","inReplyTo":"AANLkTindMBh4dzo-VG2vPrKfgNZVUhs0-5AEU2fWChaC@mail.gmail.com","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T15:33:56Z","receivedAt":"2010-12-01T15:33:56Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"2010-12-01 17:19 Erik Faye-Lund <kusmabite@gmail.com>:\n> On Wed, Dec 1, 2010 at 4:09 PM, jari <jari.aalto@cante.net> wrote:\n>\n>> On 2010-12-01 15:57, Jakub Narebski wrote:\n>> | On Wed, 1 Dec 2010, Jari Aalto wrote:\n>> | > The phone books have an index where to up information.\n>> | >\n>> | >     - When you see script and it use VARIABLE, you look it from\n>> | >       manual page\n>> |\n>> | Manpages (and 'git <cmd> --help') are displayed in pager, so you can\n>> | always search for option in a pager (e.g. '/' in 'less', the default\n>> | pager).\n>>\n>> Yuck, it's real fun start backward/forward ping-pong when you dont'\n>> know the directions and can't rely on standard A-Z index.\n>>\n>\n> ...but for config options, I tend to ping-pong between items that are\n> related to each other, which are already located close by. Your\n> argument weighs more for keeping the current layout, IMO.\n\nThis isa all academic. It's known in literature that you can't in\npractise group all related. That's why you add \"see also\".\n\n    A\n    B   references X\n    C   references A\n    D\n    E\n    F   Refrences A\n    ...\n    X\n\nSo what's the order? All related items gruped? There will always be\nzillions of related items.\n\nThe A-Z that works, always.\n\nCASE:\n\n    You read piece of ~/.gitconfig somewhere. You wonder what that\n    does. You pick up the manual, A-Z and, voila -- you know the option.\n\n    Then read next. And you know to what direction to search (A-Z). Another\n    search gone gold.\n\n    And you continue. No problems. All straight A-Z.\n\nWith \"grouped\" you just feel dizzy after a real detective work. \"Was it\nupward, downward -- Damn my pager is not even less(1)\".\n\n\nJari\n"},{"id":"156944","messageId":"87zkspv70f.fsf@picasso.cante.net","threadId":"25878","inReplyTo":"AANLkTindMBh4dzo-VG2vPrKfgNZVUhs0-5AEU2fWChaC@mail.gmail.com","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T15:37:36Z","receivedAt":"2010-12-01T15:37:36Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"2010-12-01 17:19 Erik Faye-Lund <kusmabite@gmail.com>:\n> I still haven't heard a compelling argument why alphabetical ordering\n> is better than logical ordering...\n\n>From previous mail (spelling adjusted):\n\n    \"About 60% in git-config is already in alpha order (core.*, sendmail.*\n    etc), so there is not really that much what would be changing.\"\n\nJari\n"},{"id":"156956","messageId":"201012011737.53652.jnareb@gmail.com","threadId":"25878","inReplyTo":"20101201150917.GD6537@picasso.cante.net","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-01T16:37:52Z","receivedAt":"2010-12-01T16:37:52Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia środa 1. grudnia 2010 16:09, jari napisał:\n> On 2010-12-01 15:57, Jakub Narebski wrote:\n>| On Wed, 1 Dec 2010, Jari Aalto wrote:\n>|> On 2010-12-01 05:58, Jakub Narebski wrote:\n>|>| jari.aalto@cante.net writes:\n>|>| \n>|>|> From: Jari Aalto <jari.aalto@cante.net>\n>|>|> \n>|>|> \n>|>|> Signed-off-by: Jari Aalto <jari.aalto@cante.net>\n>|>|> ---\n>|>|>  Documentation/config.txt| 1698 +++++++++++++++++++++++-----------------------\n>|>|>  1 files changed, 852 insertions(+), 846 deletions(-)\n>|>| \n>|>| Why?  What such large change is for?\n>|>| \n>|>| Note that currently config variables are grouped by functionality: for\n>|>| example core.eol and core.safecrlf, or core.compression and\n>|>| core.loosecompression are close to each other.\n>| \n>| What about the above?\n> \n> We use standard biblical refences:\n> \n> \t Se ....\n> \n> Suggest what is needed, and it will be so.\n\nHaving related config variables together is IMVHO more important than\nhaving config variables sorted alphabetically.\n\n>|> The phone books have an index where to up information.\n>|> \n>|>     - When you see script and it use VARIABLE, you look it from\n>|>       manual page\n>| \n>| Manpages (and 'git <cmd> --help') are displayed in pager, so you can\n>| always search for option in a pager (e.g. '/' in 'less', the default\n>| pager).\n> \n> Yuck, it's real fun start backward/forward ping-pong when you dont'\n> know the directions and can't rely on standard A-Z index.\n\nNo need for backward/forward, simply go to beginning ([Home]) and search\nforward (/<pattern>), or go to end ([End]) and search backward (?<pattern>).\n\n>|> It is same as putting option in alphabetical order. See GNU cp(1),\n>|> ssh(1) etc.\n>| \n>| In git documentation command line options are not in alphabetical order,\n>| but grouped by functionality, therefore your argument is invalid.\n> \n> I see that only in pages that have tens and tens and tens of options..\n\nAnd git command doesn't have tens and tens of options?\n\nBTW. you discarded my counterexamples of tar, rpm and uname.\n\n> \n> The problem is more the asciidoc's. Various bits and pices are\n> \"included\" in place and make ordering the options impossible in some\n> pages.\n> \n> Let's get all pages in shape with A-Z in this regard. That's a good\n> quality goal.\n\nIf it is impossible to have options ordered alphabetically because common\noptions are extracted to separate file and then \"included\", why bother?\n\n> \n>|> There are zillion values and for a reference, alphabetical order makes\n>|> sense.\n>| \n>| I agree that alphabetical order makes sense for glossary; I disagree that\n>| it makes sense here.\n> \n> About 60% in git-config is already in alpha order (core.*, sendmail.*\n> etc), so there is not really much that is changing.\n\ncore.* is not in alphabetical order: we have `core.eol', `core.safecrlf',\n`core.autocrlf'.\n\nsendemail.* is not fully in alphabetical order: we have \n`sendemail.smtpserverport', then `sendemail.smtpserveroption' (p-o, not\nalphabetical o-p).\n \n> Well. If standard reading order is not the standard, I don't know what\n> is.\n\nI'd rather, _if we must_, *generate* gitconfig(5) file with alphabetically\nordered configuration variables (and subvariables).\n\nFunctional grouping is IMVHO more important than alphabetical ordering.\n-- \nJakub Narebski\nPoland\n"},{"id":"156961","messageId":"87vd3dv2ow.fsf@picasso.cante.net","threadId":"25878","inReplyTo":"201012011737.53652.jnareb@gmail.com","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T17:10:55Z","receivedAt":"2010-12-01T17:10:55Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"2010-12-01 18:37 Jakub Narebski <jnareb@gmail.com>:\n> Having related config variables together is IMVHO more important than\n> having config variables sorted alphabetically.\n\nThat's subjective criteria. I doubt there are many related one that\ncan't be handled with standard \"see also\".\n\nA small percentage of variables that \"group\" is bad criteria for general\nuse. Especially when confix.txt contains somewhere 250 options.\n\nMost of the time you want to look up X. And alpha order is what doctor\nordered.\n\nSame for command line options. You read zillions of scripts and cryptic\noptions. You want to consult manual page to see what an option means. Again\nyou're searching A-Z.\n\nJari\n"},{"id":"156970","messageId":"20101201180332.GC7774@sigill.intra.peff.net","threadId":"25878","inReplyTo":"87vd3dv2ow.fsf@picasso.cante.net","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-12-01T18:03:32Z","receivedAt":"2010-12-01T18:03:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 01, 2010 at 07:10:55PM +0200, Jari Aalto wrote:\n\n> 2010-12-01 18:37 Jakub Narebski <jnareb@gmail.com>:\n> > Having related config variables together is IMVHO more important than\n> > having config variables sorted alphabetically.\n> \n> That's subjective criteria. I doubt there are many related one that\n> can't be handled with standard \"see also\".\n\nDon't we already have a plan and some patches in flight (from Thomas) to\nturn the master list into a straight one-line-per-config index (which\nprobably _should_ be alphabetized), and then put related options into\ntheir respective manpages (which effectively sorts them by\nfunctionality)?\n\nThis patch is just going to cause conflicts with Thomas's, and in the\nend will be obsoleted by it.\n\n-Peff\n"},{"id":"157060","messageId":"201012020038.55019.jnareb@gmail.com","threadId":"25878","inReplyTo":"20101201180332.GC7774@sigill.intra.peff.net","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-01T23:38:52Z","receivedAt":"2010-12-01T23:38:52Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 1 Dec 2010, Jeff King wrote:\n> On Wed, Dec 01, 2010 at 07:10:55PM +0200, Jari Aalto wrote:\n> \n> > 2010-12-01 18:37 Jakub Narebski <jnareb@gmail.com>:\n> > > Having related config variables together is IMVHO more important than\n> > > having config variables sorted alphabetically.\n> > \n> > That's subjective criteria. I doubt there are many related one that\n> > can't be handled with standard \"see also\".\n> \n> Don't we already have a plan and some patches in flight (from Thomas) to\n> turn the master list into a straight one-line-per-config index (which\n> probably _should_ be alphabetized), and then put related options into\n> their respective manpages (which effectively sorts them by\n> functionality)?\n\nActually Thomas Rast patches (the 'tr/config-doc', not even in 'pu')\nare about finding config variables referenced in individual manpages\nbut not in list of config variables, and adding reference to them in\nlist of all config variables.  Sorting list of variables is orthogonal\nto that (though first version sorted by default).\n\n> \n> This patch is just going to cause conflicts with Thomas's, and in the\n> end will be obsoleted by it.\n\nCould be obsoleted, yes (if we chose sorting).  Cause confict, no; at\nleast if first patch in series is generated by script, as described in\nhttp://permalink.gmane.org/gmane.comp.version-control.git/162145\n-- \nJakub Narebski\nPoland\n"},{"id":"157066","messageId":"20101202010229.GA4832@neumann","threadId":"25878","inReplyTo":"87vd3dv2ow.fsf@picasso.cante.net","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2010-12-02T01:02:29Z","receivedAt":"2010-12-02T01:02:29Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Dec 01, 2010 at 07:10:55PM +0200, Jari Aalto wrote:\n> 2010-12-01 18:37 Jakub Narebski <jnareb@gmail.com>:\n> > Having related config variables together is IMVHO more important than\n> > having config variables sorted alphabetically.\n> \n> That's subjective criteria.\n\nI agree with Jakub; his criteria might be subjective, but it's highly\npractical, while your examples are not.\n\n> Most of the time you want to look up X. And alpha order is what doctor\n> ordered.\n> \n> Same for command line options. You read zillions of scripts and cryptic\n> options. You want to consult manual page to see what an option means. Again\n> you're searching A-Z.\n\nWhen I want to look up X or a command line option seen somewhere, I\nnever search A-Z.  I always search using the pager's or browser's\nsearch function.  And when it found what I was searching for, then I\nmuch prefer to see related options on the same screen.\n\nBest,\nGábor\n"},{"id":"157081","messageId":"87oc94spax.fsf@picasso.cante.net","threadId":"25878","inReplyTo":"20101202010229.GA4832@neumann","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-02T05:43:02Z","receivedAt":"2010-12-02T05:43:02Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"2010-12-02 03:02 SZEDER Gábor <szeder@ira.uka.de>:\n> On Wed, Dec 01, 2010 at 07:10:55PM +0200, Jari Aalto wrote:\n>> Same for command line options. You read zillions of scripts and cryptic\n>> options. You want to consult manual page to see what an option means. Again\n>> you're searching A-Z.\n>\n> When I want to look up X or a command line option seen somewhere, I\n> never search A-Z.  I always search using the pager's or browser's\n> search function.  And when it found what I was searching for, then I\n> much prefer to see related options on the same screen.\n\nThatäs real slow method.\n\nYou don't need specific search function (or reliance on those\navailability[*]) when you can just tap\n\n    PgUp\n    PgDown\n\nto locate the information by visual cues (A-Z).\n\n[*] less(1) is not the default manual page pager everywhere.\n"},{"id":"157080","messageId":"87k4jssp5o.fsf@picasso.cante.net","threadId":"25878","inReplyTo":"20101202010229.GA4832@neumann","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-02T05:46:11Z","receivedAt":"2010-12-02T05:46:11Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"2010-12-02 03:02 SZEDER Gábor <szeder@ira.uka.de>:\n> On Wed, Dec 01, 2010 at 07:10:55PM +0200, Jari Aalto wrote:\n> search function.  And when it found what I was searching for, then I\n> much prefer to see related options on the same screen.\n\nConsider: you don't have use for additional information when you're\nlooking up the meaning of X.\n\nJari\n"},{"id":"157096","messageId":"20101202092439.GA6946@neumann","threadId":"25878","inReplyTo":"87k4jssp5o.fsf@picasso.cante.net","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2010-12-02T09:24:39Z","receivedAt":"2010-12-02T09:24:39Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Don't cull the Cc list.\n\n\nOn Thu, Dec 02, 2010 at 07:46:11AM +0200, Jari Aalto wrote:\n> 2010-12-02 03:02 SZEDER Gábor <szeder@ira.uka.de>:\n> > On Wed, Dec 01, 2010 at 07:10:55PM +0200, Jari Aalto wrote:\n> > search function.  And when it found what I was searching for, then I\n> > much prefer to see related options on the same screen.\n> \n> Consider: you don't have use for additional information when you're\n> looking up the meaning of X.\n\nMany a times I do need that additional information.\n\n\nHtH,\nGábor\n"},{"id":"157097","messageId":"20101202093258.GA7035@neumann","threadId":"25878","inReplyTo":"87oc94spax.fsf@picasso.cante.net","subject":"Re: [PATCH] Documentation/config.txt: Order variables alphabetically","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2010-12-02T09:32:58Z","receivedAt":"2010-12-02T09:32:58Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Don't cull the Cc list.\n\n\nOn Thu, Dec 02, 2010 at 07:43:02AM +0200, Jari Aalto wrote:\n> 2010-12-02 03:02 SZEDER Gábor <szeder@ira.uka.de>:\n> > On Wed, Dec 01, 2010 at 07:10:55PM +0200, Jari Aalto wrote:\n> >> Same for command line options. You read zillions of scripts and cryptic\n> >> options. You want to consult manual page to see what an option means. Again\n> >> you're searching A-Z.\n> >\n> > When I want to look up X or a command line option seen somewhere, I\n> > never search A-Z.  I always search using the pager's or browser's\n> > search function.  And when it found what I was searching for, then I\n> > much prefer to see related options on the same screen.\n> \n> Thatäs real slow method.\n\nBased on my own experience, I disagree, ...\n\n> You don't need specific search function (or reliance on those\n> availability[*]) when you can just tap\n> \n>     PgUp\n>     PgDown\n> \n> to locate the information by visual cues (A-Z).\n\n... and therefore I much prefer using the search function.\n\n> [*] less(1) is not the default manual page pager everywhere.\n\nI assume that nowadays search-capable pagers are much more widespread\nthan non-search-capable ones.\n\n\nGábor\n"}]}