Documentation / config.txton commit Increase pack.depth default to 50 (618e613)
   1CONFIGURATION FILE
   2------------------
   3
   4The git configuration file contains a number of variables that affect
   5the git command's behavior. `.git/config` file for each repository
   6is used to store the information for that repository, and
   7`$HOME/.gitconfig` is used to store per user information to give
   8fallback values for `.git/config` file. The file `/etc/gitconfig`
   9can be used to store system-wide defaults.
  10
  11They can be used by both the git plumbing
  12and the porcelains. The variables are divided into sections, where
  13in the fully qualified variable name the variable itself is the last
  14dot-separated segment and the section name is everything before the last
  15dot. The variable names are case-insensitive and only alphanumeric
  16characters are allowed. Some variables may appear multiple times.
  17
  18Syntax
  19~~~~~~
  20
  21The syntax is fairly flexible and permissive; whitespaces are mostly
  22ignored.  The '#' and ';' characters begin comments to the end of line,
  23blank lines are ignored.
  24
  25The file consists of sections and variables.  A section begins with
  26the name of the section in square brackets and continues until the next
  27section begins.  Section names are not case sensitive.  Only alphanumeric
  28characters, '`-`' and '`.`' are allowed in section names.  Each variable
  29must belong to some section, which means that there must be section
  30header before first setting of a variable.
  31
  32Sections can be further divided into subsections.  To begin a subsection
  33put its name in double quotes, separated by space from the section name,
  34in the section header, like in example below:
  35
  36--------
  37        [section "subsection"]
  38
  39--------
  40
  41Subsection names can contain any characters except newline (doublequote
  42'`"`' and backslash have to be escaped as '`\"`' and '`\\`',
  43respectively) and are case sensitive.  Section header cannot span multiple
  44lines.  Variables may belong directly to a section or to a given subsection.
  45You can have `[section]` if you have `[section "subsection"]`, but you
  46don't need to.
  47
  48There is also (case insensitive) alternative `[section.subsection]` syntax.
  49In this syntax subsection names follow the same restrictions as for section
  50name.
  51
  52All the other lines are recognized as setting variables, in the form
  53'name = value'.  If there is no equal sign on the line, the entire line
  54is taken as 'name' and the variable is recognized as boolean "true".
  55The variable names are case-insensitive and only alphanumeric
  56characters and '`-`' are allowed.  There can be more than one value
  57for a given variable; we say then that variable is multivalued.
  58
  59Leading and trailing whitespace in a variable value is discarded.
  60Internal whitespace within a variable value is retained verbatim.
  61
  62The values following the equals sign in variable assign are all either
  63a string, an integer, or a boolean.  Boolean values may be given as yes/no,
  640/1 or true/false.  Case is not significant in boolean values, when
  65converting value to the canonical form using '--bool' type specifier;
  66`git-config` will ensure that the output is "true" or "false".
  67
  68String values may be entirely or partially enclosed in double quotes.
  69You need to enclose variable value in double quotes if you want to
  70preserve leading or trailing whitespace, or if variable value contains
  71beginning of comment characters (if it contains '#' or ';').
  72Double quote '`"`' and backslash '`\`' characters in variable value must
  73be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
  74
  75The following escape sequences (beside '`\"`' and '`\\`') are recognized:
  76'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
  77and '`\b`' for backspace (BS).  No other char escape sequence, nor octal
  78char sequences are valid.
  79
  80Variable value ending in a '`\`' is continued on the next line in the
  81customary UNIX fashion.
  82
  83Some variables may require special value format.
  84
  85Example
  86~~~~~~~
  87
  88        # Core variables
  89        [core]
  90                ; Don't trust file modes
  91                filemode = false
  92
  93        # Our diff algorithm
  94        [diff]
  95                external = "/usr/local/bin/gnu-diff -u"
  96                renames = true
  97
  98        [branch "devel"]
  99                remote = origin
 100                merge = refs/heads/devel
 101
 102        # Proxy settings
 103        [core]
 104                gitProxy="ssh" for "ssh://kernel.org/"
 105                gitProxy=default-proxy ; for the rest
 106
 107Variables
 108~~~~~~~~~
 109
 110Note that this list is non-comprehensive and not necessarily complete.
 111For command-specific variables, you will find a more detailed description
 112in the appropriate manual page. You will find a description of non-core
 113porcelain configuration variables in the respective porcelain documentation.
 114
 115core.fileMode::
 116        If false, the executable bit differences between the index and
 117        the working copy are ignored; useful on broken filesystems like FAT.
 118        See gitlink:git-update-index[1]. True by default.
 119
 120core.autocrlf::
 121        If true, makes git convert `CRLF` at the end of lines in text files to
 122        `LF` when reading from the filesystem, and convert in reverse when
 123        writing to the filesystem.  The variable can be set to
 124        'input', in which case the conversion happens only while
 125        reading from the filesystem but files are written out with
 126        `LF` at the end of lines.  Currently, which paths to consider
 127        "text" (i.e. be subjected to the autocrlf mechanism) is
 128        decided purely based on the contents.
 129
 130core.symlinks::
 131        If false, symbolic links are checked out as small plain files that
 132        contain the link text. gitlink:git-update-index[1] and
 133        gitlink:git-add[1] will not change the recorded type to regular
 134        file. Useful on filesystems like FAT that do not support
 135        symbolic links. True by default.
 136
 137core.gitProxy::
 138        A "proxy command" to execute (as 'command host port') instead
 139        of establishing direct connection to the remote server when
 140        using the git protocol for fetching. If the variable value is
 141        in the "COMMAND for DOMAIN" format, the command is applied only
 142        on hostnames ending with the specified domain string. This variable
 143        may be set multiple times and is matched in the given order;
 144        the first match wins.
 145+
 146Can be overridden by the 'GIT_PROXY_COMMAND' environment variable
 147(which always applies universally, without the special "for"
 148handling).
 149
 150core.ignoreStat::
 151        The working copy files are assumed to stay unchanged until you
 152        mark them otherwise manually - Git will not detect the file changes
 153        by lstat() calls. This is useful on systems where those are very
 154        slow, such as Microsoft Windows.  See gitlink:git-update-index[1].
 155        False by default.
 156
 157core.preferSymlinkRefs::
 158        Instead of the default "symref" format for HEAD
 159        and other symbolic reference files, use symbolic links.
 160        This is sometimes needed to work with old scripts that
 161        expect HEAD to be a symbolic link.
 162
 163core.bare::
 164        If true this repository is assumed to be 'bare' and has no
 165        working directory associated with it.  If this is the case a
 166        number of commands that require a working directory will be
 167        disabled, such as gitlink:git-add[1] or gitlink:git-merge[1].
 168+
 169This setting is automatically guessed by gitlink:git-clone[1] or
 170gitlink:git-init[1] when the repository was created.  By default a
 171repository that ends in "/.git" is assumed to be not bare (bare =
 172false), while all other repositories are assumed to be bare (bare
 173= true).
 174
 175core.logAllRefUpdates::
 176        Updates to a ref <ref> is logged to the file
 177        "$GIT_DIR/logs/<ref>", by appending the new and old
 178        SHA1, the date/time and the reason of the update, but
 179        only when the file exists.  If this configuration
 180        variable is set to true, missing "$GIT_DIR/logs/<ref>"
 181        file is automatically created for branch heads.
 182+
 183This information can be used to determine what commit
 184was the tip of a branch "2 days ago".
 185+
 186This value is true by default in a repository that has
 187a working directory associated with it, and false by
 188default in a bare repository.
 189
 190core.repositoryFormatVersion::
 191        Internal variable identifying the repository format and layout
 192        version.
 193
 194core.sharedRepository::
 195        When 'group' (or 'true'), the repository is made shareable between
 196        several users in a group (making sure all the files and objects are
 197        group-writable). When 'all' (or 'world' or 'everybody'), the
 198        repository will be readable by all users, additionally to being
 199        group-shareable. When 'umask' (or 'false'), git will use permissions
 200        reported by umask(2). See gitlink:git-init[1]. False by default.
 201
 202core.warnAmbiguousRefs::
 203        If true, git will warn you if the ref name you passed it is ambiguous
 204        and might match multiple refs in the .git/refs/ tree. True by default.
 205
 206core.compression::
 207        An integer -1..9, indicating the compression level for objects that
 208        are not in a pack file. -1 is the zlib and git default. 0 means no
 209        compression, and 1..9 are various speed/size tradeoffs, 9 being
 210        slowest.
 211
 212core.legacyheaders::
 213        A boolean which
 214        changes the format of loose objects so that they are more
 215        efficient to pack and to send out of the repository over git
 216        native protocol, since v1.4.2.  However, loose objects
 217        written in the new format cannot be read by git older than
 218        that version; people fetching from your repository using
 219        older versions of git over dumb transports (e.g. http)
 220        will also be affected.
 221+
 222To let git use the new loose object format, you have to
 223set core.legacyheaders to false.
 224
 225core.packedGitWindowSize::
 226        Number of bytes of a pack file to map into memory in a
 227        single mapping operation.  Larger window sizes may allow
 228        your system to process a smaller number of large pack files
 229        more quickly.  Smaller window sizes will negatively affect
 230        performance due to increased calls to the operating system's
 231        memory manager, but may improve performance when accessing
 232        a large number of large pack files.
 233+
 234Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
 235MiB on 32 bit platforms and 1 GiB on 64 bit platforms.  This should
 236be reasonable for all users/operating systems.  You probably do
 237not need to adjust this value.
 238+
 239Common unit suffixes of 'k', 'm', or 'g' are supported.
 240
 241core.packedGitLimit::
 242        Maximum number of bytes to map simultaneously into memory
 243        from pack files.  If Git needs to access more than this many
 244        bytes at once to complete an operation it will unmap existing
 245        regions to reclaim virtual address space within the process.
 246+
 247Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
 248This should be reasonable for all users/operating systems, except on
 249the largest projects.  You probably do not need to adjust this value.
 250+
 251Common unit suffixes of 'k', 'm', or 'g' are supported.
 252
 253core.deltaBaseCacheLimit::
 254        Maximum number of bytes to reserve for caching base objects
 255        that multiple deltafied objects reference.  By storing the
 256        entire decompressed base objects in a cache Git is able
 257        to avoid unpacking and decompressing frequently used base
 258        objects multiple times.
 259+
 260Default is 16 MiB on all platforms.  This should be reasonable
 261for all users/operating systems, except on the largest projects.
 262You probably do not need to adjust this value.
 263+
 264Common unit suffixes of 'k', 'm', or 'g' are supported.
 265
 266alias.*::
 267        Command aliases for the gitlink:git[1] command wrapper - e.g.
 268        after defining "alias.last = cat-file commit HEAD", the invocation
 269        "git last" is equivalent to "git cat-file commit HEAD". To avoid
 270        confusion and troubles with script usage, aliases that
 271        hide existing git commands are ignored. Arguments are split by
 272        spaces, the usual shell quoting and escaping is supported.
 273        quote pair and a backslash can be used to quote them.
 274
 275        If the alias expansion is prefixed with an exclamation point,
 276        it will be treated as a shell command.  For example, defining
 277        "alias.new = !gitk --all --not ORIG_HEAD", the invocation
 278        "git new" is equivalent to running the shell command
 279        "gitk --all --not ORIG_HEAD".
 280
 281apply.whitespace::
 282        Tells `git-apply` how to handle whitespaces, in the same way
 283        as the '--whitespace' option. See gitlink:git-apply[1].
 284
 285branch.<name>.remote::
 286        When in branch <name>, it tells `git fetch` which remote to fetch.
 287        If this option is not given, `git fetch` defaults to remote "origin".
 288
 289branch.<name>.merge::
 290        When in branch <name>, it tells `git fetch` the default refspec to
 291        be marked for merging in FETCH_HEAD. The value has exactly to match
 292        a remote part of one of the refspecs which are fetched from the remote
 293        given by "branch.<name>.remote".
 294        The merge information is used by `git pull` (which at first calls
 295        `git fetch`) to lookup the default branch for merging. Without
 296        this option, `git pull` defaults to merge the first refspec fetched.
 297        Specify multiple values to get an octopus merge.
 298        If you wish to setup `git pull` so that it merges into <name> from
 299        another branch in the local repository, you can point
 300        branch.<name>.merge to the desired branch, and use the special setting
 301        `.` (a period) for branch.<name>.remote.
 302
 303clean.requireForce::
 304        A boolean to make git-clean do nothing unless given -f or -n.  Defaults
 305        to false.
 306
 307color.branch::
 308        A boolean to enable/disable color in the output of
 309        gitlink:git-branch[1]. May be set to `true` (or `always`),
 310        `false` (or `never`) or `auto`, in which case colors are used
 311        only when the output is to a terminal. Defaults to false.
 312
 313color.branch.<slot>::
 314        Use customized color for branch coloration. `<slot>` is one of
 315        `current` (the current branch), `local` (a local branch),
 316        `remote` (a tracking branch in refs/remotes/), `plain` (other
 317        refs).
 318+
 319The value for these configuration variables is a list of colors (at most
 320two) and attributes (at most one), separated by spaces.  The colors
 321accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,
 322`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,
 323`blink` and `reverse`.  The first color given is the foreground; the
 324second is the background.  The position of the attribute, if any,
 325doesn't matter.
 326
 327color.diff::
 328        When true (or `always`), always use colors in patch.
 329        When false (or `never`), never.  When set to `auto`, use
 330        colors only when the output is to the terminal.
 331
 332color.diff.<slot>::
 333        Use customized color for diff colorization.  `<slot>` specifies
 334        which part of the patch to use the specified color, and is one
 335        of `plain` (context text), `meta` (metainformation), `frag`
 336        (hunk header), `old` (removed lines), `new` (added lines),
 337        `commit` (commit headers), or `whitespace` (highlighting dubious
 338        whitespace).  The values of these variables may be specified as
 339        in color.branch.<slot>.
 340
 341color.pager::
 342        A boolean to enable/disable colored output when the pager is in
 343        use (default is true).
 344
 345color.status::
 346        A boolean to enable/disable color in the output of
 347        gitlink:git-status[1]. May be set to `true` (or `always`),
 348        `false` (or `never`) or `auto`, in which case colors are used
 349        only when the output is to a terminal. Defaults to false.
 350
 351color.status.<slot>::
 352        Use customized color for status colorization. `<slot>` is
 353        one of `header` (the header text of the status message),
 354        `added` or `updated` (files which are added but not committed),
 355        `changed` (files which are changed but not added in the index),
 356        or `untracked` (files which are not tracked by git). The values of
 357        these variables may be specified as in color.branch.<slot>.
 358
 359diff.renameLimit::
 360        The number of files to consider when performing the copy/rename
 361        detection; equivalent to the git diff option '-l'.
 362
 363diff.renames::
 364        Tells git to detect renames.  If set to any boolean value, it
 365        will enable basic rename detection.  If set to "copies" or
 366        "copy", it will detect copies, as well.
 367
 368fetch.unpackLimit::
 369        If the number of objects fetched over the git native
 370        transfer is below this
 371        limit, then the objects will be unpacked into loose object
 372        files. However if the number of received objects equals or
 373        exceeds this limit then the received pack will be stored as
 374        a pack, after adding any missing delta bases.  Storing the
 375        pack from a push can make the push operation complete faster,
 376        especially on slow filesystems.
 377
 378format.headers::
 379        Additional email headers to include in a patch to be submitted
 380        by mail.  See gitlink:git-format-patch[1].
 381
 382format.suffix::
 383        The default for format-patch is to output files with the suffix
 384        `.patch`. Use this variable to change that suffix (make sure to
 385        include the dot if you want it).
 386
 387gc.packrefs::
 388        `git gc` does not run `git pack-refs` in a bare repository by
 389        default so that older dumb-transport clients can still fetch
 390        from the repository.  Setting this to `true` lets `git
 391        gc` to run `git pack-refs`.  Setting this to `false` tells
 392        `git gc` never to run `git pack-refs`. The default setting is
 393        `notbare`. Enable it only when you know you do not have to
 394        support such clients.  The default setting will change to `true`
 395        at some stage, and setting this to `false` will continue to
 396        prevent `git pack-refs` from being run from `git gc`.
 397
 398gc.reflogexpire::
 399        `git reflog expire` removes reflog entries older than
 400        this time; defaults to 90 days.
 401
 402gc.reflogexpireunreachable::
 403        `git reflog expire` removes reflog entries older than
 404        this time and are not reachable from the current tip;
 405        defaults to 30 days.
 406
 407gc.rerereresolved::
 408        Records of conflicted merge you resolved earlier are
 409        kept for this many days when `git rerere gc` is run.
 410        The default is 60 days.  See gitlink:git-rerere[1].
 411
 412gc.rerereunresolved::
 413        Records of conflicted merge you have not resolved are
 414        kept for this many days when `git rerere gc` is run.
 415        The default is 15 days.  See gitlink:git-rerere[1].
 416
 417gitcvs.enabled::
 418        Whether the cvs server interface is enabled for this repository.
 419        See gitlink:git-cvsserver[1].
 420
 421gitcvs.logfile::
 422        Path to a log file where the cvs server interface well... logs
 423        various stuff. See gitlink:git-cvsserver[1].
 424
 425gitcvs.allbinary::
 426        If true, all files are sent to the client in mode '-kb'. This
 427        causes the client to treat all files as binary files which suppresses
 428        any newline munging it otherwise might do. A work-around for the
 429        fact that there is no way yet to set single files to mode '-kb'.
 430
 431gitcvs.dbname::
 432        Database used by git-cvsserver to cache revision information
 433        derived from the git repository. The exact meaning depends on the
 434        used database driver, for SQLite (which is the default driver) this
 435        is a filename. Supports variable substitution (see
 436        gitlink:git-cvsserver[1] for details). May not contain semicolons (`;`).
 437        Default: '%Ggitcvs.%m.sqlite'
 438
 439gitcvs.dbdriver::
 440        Used Perl DBI driver. You can specify any available driver
 441        for this here, but it might not work. git-cvsserver is tested
 442        with 'DBD::SQLite', reported to work with 'DBD::Pg', and
 443        reported *not* to work with 'DBD::mysql'. Experimental feature.
 444        May not contain double colons (`:`). Default: 'SQLite'.
 445        See gitlink:git-cvsserver[1].
 446
 447gitcvs.dbuser, gitcvs.dbpass::
 448        Database user and password. Only useful if setting 'gitcvs.dbdriver',
 449        since SQLite has no concept of database users and/or passwords.
 450        'gitcvs.dbuser' supports variable substitution (see
 451        gitlink:git-cvsserver[1] for details).
 452
 453All gitcvs variables except for 'gitcvs.allbinary' can also specifed
 454as 'gitcvs.<access_method>.<varname>' (where 'access_method' is one
 455of "ext" and "pserver") to make them apply only for the given access
 456method.
 457
 458http.sslVerify::
 459        Whether to verify the SSL certificate when fetching or pushing
 460        over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment
 461        variable.
 462
 463http.sslCert::
 464        File containing the SSL certificate when fetching or pushing
 465        over HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment
 466        variable.
 467
 468http.sslKey::
 469        File containing the SSL private key when fetching or pushing
 470        over HTTPS. Can be overridden by the 'GIT_SSL_KEY' environment
 471        variable.
 472
 473http.sslCAInfo::
 474        File containing the certificates to verify the peer with when
 475        fetching or pushing over HTTPS. Can be overridden by the
 476        'GIT_SSL_CAINFO' environment variable.
 477
 478http.sslCAPath::
 479        Path containing files with the CA certificates to verify the peer
 480        with when fetching or pushing over HTTPS. Can be overridden
 481        by the 'GIT_SSL_CAPATH' environment variable.
 482
 483http.maxRequests::
 484        How many HTTP requests to launch in parallel. Can be overridden
 485        by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
 486
 487http.lowSpeedLimit, http.lowSpeedTime::
 488        If the HTTP transfer speed is less than 'http.lowSpeedLimit'
 489        for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
 490        Can be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and
 491        'GIT_HTTP_LOW_SPEED_TIME' environment variables.
 492
 493http.noEPSV::
 494        A boolean which disables using of EPSV ftp command by curl.
 495        This can helpful with some "poor" ftp servers which don't
 496        support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
 497        environment variable. Default is false (curl will use EPSV).
 498
 499i18n.commitEncoding::
 500        Character encoding the commit messages are stored in; git itself
 501        does not care per se, but this information is necessary e.g. when
 502        importing commits from emails or in the gitk graphical history
 503        browser (and possibly at other places in the future or in other
 504        porcelains). See e.g. gitlink:git-mailinfo[1]. Defaults to 'utf-8'.
 505
 506i18n.logOutputEncoding::
 507        Character encoding the commit messages are converted to when
 508        running `git-log` and friends.
 509
 510log.showroot::
 511        If true, the initial commit will be shown as a big creation event.
 512        This is equivalent to a diff against an empty tree.
 513        Tools like gitlink:git-log[1] or gitlink:git-whatchanged[1], which
 514        normally hide the root commit will now show it. True by default.
 515
 516merge.summary::
 517        Whether to include summaries of merged commits in newly created
 518        merge commit messages. False by default.
 519
 520merge.tool::
 521        Controls which merge resolution program is used by
 522        gitlink:git-mergetool[l].  Valid values are: "kdiff3", "tkdiff",
 523        "meld", "xxdiff", "emerge", "vimdiff", and "opendiff"
 524
 525merge.verbosity::
 526        Controls the amount of output shown by the recursive merge
 527        strategy.  Level 0 outputs nothing except a final error
 528        message if conflicts were detected. Level 1 outputs only
 529        conflicts, 2 outputs conflicts and file changes.  Level 5 and
 530        above outputs debugging information.  The default is level 2.
 531
 532merge.<driver>.name::
 533        Defines a human readable name for a custom low-level
 534        merge driver.  See gitlink:gitattributes[5] for details.
 535
 536merge.<driver>.driver::
 537        Defines the command that implements a custom low-level
 538        merge driver.  See gitlink:gitattributes[5] for details.
 539
 540merge.<driver>.recursive::
 541        Names a low-level merge driver to be used when
 542        performing an internal merge between common ancestors.
 543        See gitlink:gitattributes[5] for details.
 544
 545pack.window::
 546        The size of the window used by gitlink:git-pack-objects[1] when no
 547        window size is given on the command line. Defaults to 10.
 548
 549pack.depth::
 550        The maximum delta depth used by gitlink:git-pack-objects[1] when no
 551        maximum depth is given on the command line. Defaults to 50.
 552
 553pull.octopus::
 554        The default merge strategy to use when pulling multiple branches
 555        at once.
 556
 557pull.twohead::
 558        The default merge strategy to use when pulling a single branch.
 559
 560remote.<name>.url::
 561        The URL of a remote repository.  See gitlink:git-fetch[1] or
 562        gitlink:git-push[1].
 563
 564remote.<name>.fetch::
 565        The default set of "refspec" for gitlink:git-fetch[1]. See
 566        gitlink:git-fetch[1].
 567
 568remote.<name>.push::
 569        The default set of "refspec" for gitlink:git-push[1]. See
 570        gitlink:git-push[1].
 571
 572remote.<name>.skipDefaultUpdate::
 573        If true, this remote will be skipped by default when updating
 574        using the remote subcommand of gitlink:git-remote[1].
 575
 576remote.<name>.receivepack::
 577        The default program to execute on the remote side when pushing.  See
 578        option \--exec of gitlink:git-push[1].
 579
 580remote.<name>.uploadpack::
 581        The default program to execute on the remote side when fetching.  See
 582        option \--exec of gitlink:git-fetch-pack[1].
 583
 584remote.<name>.tagopt::
 585        Setting this value to --no-tags disables automatic tag following when fetching
 586        from remote <name>
 587
 588remotes.<group>::
 589        The list of remotes which are fetched by "git remote update
 590        <group>".  See gitlink:git-remote[1].
 591
 592repack.usedeltabaseoffset::
 593        Allow gitlink:git-repack[1] to create packs that uses
 594        delta-base offset.  Defaults to false.
 595
 596show.difftree::
 597        The default gitlink:git-diff-tree[1] arguments to be used
 598        for gitlink:git-show[1].
 599
 600showbranch.default::
 601        The default set of branches for gitlink:git-show-branch[1].
 602        See gitlink:git-show-branch[1].
 603
 604tar.umask::
 605        By default, gitlink:git-tar-tree[1] sets file and directories modes
 606        to 0666 or 0777. While this is both useful and acceptable for projects
 607        such as the Linux Kernel, it might be excessive for other projects.
 608        With this variable, it becomes possible to tell
 609        gitlink:git-tar-tree[1] to apply a specific umask to the modes above.
 610        The special value "user" indicates that the user's current umask will
 611        be used. This should be enough for most projects, as it will lead to
 612        the same permissions as gitlink:git-checkout[1] would use. The default
 613        value remains 0, which means world read-write.
 614
 615user.email::
 616        Your email address to be recorded in any newly created commits.
 617        Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
 618        'EMAIL' environment variables.  See gitlink:git-commit-tree[1].
 619
 620user.name::
 621        Your full name to be recorded in any newly created commits.
 622        Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
 623        environment variables.  See gitlink:git-commit-tree[1].
 624
 625user.signingkey::
 626        If gitlink:git-tag[1] is not selecting the key you want it to
 627        automatically when creating a signed tag, you can override the
 628        default selection with this variable.  This option is passed
 629        unchanged to gpg's --local-user parameter, so you may specify a key
 630        using any method that gpg supports.
 631
 632whatchanged.difftree::
 633        The default gitlink:git-diff-tree[1] arguments to be used
 634        for gitlink:git-whatchanged[1].
 635
 636imap::
 637        The configuration variables in the 'imap' section are described
 638        in gitlink:git-imap-send[1].
 639
 640receive.unpackLimit::
 641        If the number of objects received in a push is below this
 642        limit then the objects will be unpacked into loose object
 643        files. However if the number of received objects equals or
 644        exceeds this limit then the received pack will be stored as
 645        a pack, after adding any missing delta bases.  Storing the
 646        pack from a push can make the push operation complete faster,
 647        especially on slow filesystems.
 648
 649receive.denyNonFastForwards::
 650        If set to true, git-receive-pack will deny a ref update which is
 651        not a fast forward. Use this to prevent such an update via a push,
 652        even if that push is forced. This configuration variable is
 653        set when initializing a shared repository.
 654
 655transfer.unpackLimit::
 656        When `fetch.unpackLimit` or `receive.unpackLimit` are
 657        not set, the value of this variable is used instead.
 658
 659