------------------
The Git configuration file contains a number of variables that affect
-the Git commands' behavior. The `.git/config` file in each repository
-is used to store the configuration for that repository, and
+the Git commands' behavior. The files `.git/config` and optionally
+`config.worktree` (see `extensions.worktreeConfig` below) in each
+repository are used to store the configuration for that repository, and
`$HOME/.gitconfig` is used to store a per-user configuration as
fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store a system-wide default configuration.
include::config/mergetool.txt[]
-notes.mergeStrategy::
- Which merge strategy to choose by default when resolving notes
- conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or
- `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES"
- section of linkgit:git-notes[1] for more information on each strategy.
-
-notes.<name>.mergeStrategy::
- Which merge strategy to choose when doing a notes merge into
- refs/notes/<name>. This overrides the more general
- "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in
- linkgit:git-notes[1] for more information on the available strategies.
-
-notes.displayRef::
- The (fully qualified) refname from which to show notes when
- showing commit messages. The value of this variable can be set
- to a glob, in which case notes from all matching refs will be
- shown. You may also specify this configuration variable
- several times. A warning will be issued for refs that do not
- exist, but a glob that does not match any refs is silently
- ignored.
-+
-This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
-environment variable, which must be a colon separated list of refs or
-globs.
-+
-The effective value of "core.notesRef" (possibly overridden by
-GIT_NOTES_REF) is also implicitly added to the list of refs to be
-displayed.
-
-notes.rewrite.<command>::
- When rewriting commits with <command> (currently `amend` or
- `rebase`) and this variable is set to `true`, Git
- automatically copies your notes from the original to the
- rewritten commit. Defaults to `true`, but see
- "notes.rewriteRef" below.
-
-notes.rewriteMode::
- When copying notes during a rewrite (see the
- "notes.rewrite.<command>" option), determines what to do if
- the target commit already has a note. Must be one of
- `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
- Defaults to `concatenate`.
-+
-This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
-environment variable.
-
-notes.rewriteRef::
- When copying notes during a rewrite, specifies the (fully
- qualified) ref whose notes should be copied. The ref may be a
- glob, in which case notes in all matching refs will be copied.
- You may also specify this configuration several times.
-+
-Does not have a default value; you must configure this variable to
-enable note rewriting. Set it to `refs/notes/commits` to enable
-rewriting for the default commit notes.
-+
-This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
-environment variable, which must be a colon separated list of refs or
-globs.
-
-pack.window::
- The size of the window used by linkgit:git-pack-objects[1] when no
- window size is given on the command line. Defaults to 10.
-
-pack.depth::
- The maximum delta depth used by linkgit:git-pack-objects[1] when no
- maximum depth is given on the command line. Defaults to 50.
- Maximum value is 4095.
-
-pack.windowMemory::
- The maximum size of memory that is consumed by each thread
- in linkgit:git-pack-objects[1] for pack window memory when
- no limit is given on the command line. The value can be
- suffixed with "k", "m", or "g". When left unconfigured (or
- set explicitly to 0), there will be no limit.
-
-pack.compression::
- An integer -1..9, indicating the compression level for objects
- in a pack file. -1 is the zlib default. 0 means no
- compression, and 1..9 are various speed/size tradeoffs, 9 being
- slowest. If not set, defaults to core.compression. If that is
- not set, defaults to -1, the zlib default, which is "a default
- compromise between speed and compression (currently equivalent
- to level 6)."
-+
-Note that changing the compression level will not automatically recompress
-all existing objects. You can force recompression by passing the -F option
-to linkgit:git-repack[1].
-
-pack.island::
- An extended regular expression configuring a set of delta
- islands. See "DELTA ISLANDS" in linkgit:git-pack-objects[1]
- for details.
-
-pack.islandCore::
- Specify an island name which gets to have its objects be
- packed first. This creates a kind of pseudo-pack at the front
- of one pack, so that the objects from the specified island are
- hopefully faster to copy into any pack that should be served
- to a user requesting these objects. In practice this means
- that the island specified should likely correspond to what is
- the most commonly cloned in the repo. See also "DELTA ISLANDS"
- in linkgit:git-pack-objects[1].
-
-pack.deltaCacheSize::
- The maximum memory in bytes used for caching deltas in
- linkgit:git-pack-objects[1] before writing them out to a pack.
- This cache is used to speed up the writing object phase by not
- having to recompute the final delta result once the best match
- for all objects is found. Repacking large repositories on machines
- which are tight with memory might be badly impacted by this though,
- especially if this cache pushes the system into swapping.
- A value of 0 means no limit. The smallest size of 1 byte may be
- used to virtually disable this cache. Defaults to 256 MiB.
-
-pack.deltaCacheLimit::
- The maximum size of a delta, that is cached in
- linkgit:git-pack-objects[1]. This cache is used to speed up the
- writing object phase by not having to recompute the final delta
- result once the best match for all objects is found.
- Defaults to 1000. Maximum value is 65535.
-
-pack.threads::
- Specifies the number of threads to spawn when searching for best
- delta matches. This requires that linkgit:git-pack-objects[1]
- be compiled with pthreads otherwise this option is ignored with a
- warning. This is meant to reduce packing time on multiprocessor
- machines. The required amount of memory for the delta search window
- is however multiplied by the number of threads.
- Specifying 0 will cause Git to auto-detect the number of CPU's
- and set the number of threads accordingly.
-
-pack.indexVersion::
- Specify the default pack index version. Valid values are 1 for
- legacy pack index used by Git versions prior to 1.5.2, and 2 for
- the new pack index with capabilities for packs larger than 4 GB
- as well as proper protection against the repacking of corrupted
- packs. Version 2 is the default. Note that version 2 is enforced
- and this config option ignored whenever the corresponding pack is
- larger than 2 GB.
-+
-If you have an old Git that does not understand the version 2 `*.idx` file,
-cloning or fetching over a non native protocol (e.g. "http")
-that will copy both `*.pack` file and corresponding `*.idx` file from the
-other side may give you a repository that cannot be accessed with your
-older version of Git. If the `*.pack` file is smaller than 2 GB, however,
-you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
-the `*.idx` file.
-
-pack.packSizeLimit::
- The maximum size of a pack. This setting only affects
- packing to a file when repacking, i.e. the git:// protocol
- is unaffected. It can be overridden by the `--max-pack-size`
- option of linkgit:git-repack[1]. Reaching this limit results
- in the creation of multiple packfiles; which in turn prevents
- bitmaps from being created.
- The minimum size allowed is limited to 1 MiB.
- The default is unlimited.
- Common unit suffixes of 'k', 'm', or 'g' are
- supported.
-
-pack.useBitmaps::
- When true, git will use pack bitmaps (if available) when packing
- to stdout (e.g., during the server side of a fetch). Defaults to
- true. You should not generally need to turn this off unless
- you are debugging pack bitmaps.
-
-pack.writeBitmaps (deprecated)::
- This is a deprecated synonym for `repack.writeBitmaps`.
-
-pack.writeBitmapHashCache::
- When true, git will include a "hash cache" section in the bitmap
- index (if one is written). This cache can be used to feed git's
- delta heuristics, potentially leading to better deltas between
- bitmapped and non-bitmapped objects (e.g., when serving a fetch
- between an older, bitmapped pack and objects that have been
- pushed since the last gc). The downside is that it consumes 4
- bytes per object of disk space, and that JGit's bitmap
- implementation does not understand it, causing it to complain if
- Git and JGit are used on the same repository. Defaults to false.
-
-pager.<cmd>::
- If the value is boolean, turns on or off pagination of the
- output of a particular Git subcommand when writing to a tty.
- Otherwise, turns on pagination for the subcommand using the
- pager specified by the value of `pager.<cmd>`. If `--paginate`
- or `--no-pager` is specified on the command line, it takes
- precedence over this option. To disable pagination for all
- commands, set `core.pager` or `GIT_PAGER` to `cat`.
-
-pretty.<name>::
- Alias for a --pretty= format string, as specified in
- linkgit:git-log[1]. Any aliases defined here can be used just
- as the built-in pretty formats could. For example,
- running `git config pretty.changelog "format:* %H %s"`
- would cause the invocation `git log --pretty=changelog`
- to be equivalent to running `git log "--pretty=format:* %H %s"`.
- Note that an alias with the same name as a built-in format
- will be silently ignored.
-
-protocol.allow::
- If set, provide a user defined default policy for all protocols which
- don't explicitly have a policy (`protocol.<name>.allow`). By default,
- if unset, known-safe protocols (http, https, git, ssh, file) have a
- default policy of `always`, known-dangerous protocols (ext) have a
- default policy of `never`, and all other protocols have a default
- policy of `user`. Supported policies:
-+
---
+include::config/notes.txt[]
-* `always` - protocol is always able to be used.
+include::config/pack.txt[]
-* `never` - protocol is never able to be used.
+include::config/pager.txt[]
-* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
- either unset or has a value of 1. This policy should be used when you want a
- protocol to be directly usable by the user but don't want it used by commands which
- execute clone/fetch/push commands without user input, e.g. recursive
- submodule initialization.
+include::config/pretty.txt[]
---
+include::config/protocol.txt[]
-protocol.<name>.allow::
- Set a policy to be used by protocol `<name>` with clone/fetch/push
- commands. See `protocol.allow` above for the available policies.
-+
-The protocol names currently used by git are:
-+
---
- - `file`: any local file-based path (including `file://` URLs,
- or local paths)
-
- - `git`: the anonymous git protocol over a direct TCP
- connection (or proxy, if configured)
-
- - `ssh`: git over ssh (including `host:path` syntax,
- `ssh://`, etc).
-
- - `http`: git over http, both "smart http" and "dumb http".
- Note that this does _not_ include `https`; if you want to configure
- both, you must do so individually.
-
- - any external helpers are named by their protocol (e.g., use
- `hg` to allow the `git-remote-hg` helper)
---
-
-protocol.version::
- Experimental. If set, clients will attempt to communicate with a
- server using the specified protocol version. If unset, no
- attempt will be made by the client to communicate using a
- particular protocol version, this results in protocol version 0
- being used.
- Supported versions:
-+
---
-
-* `0` - the original wire protocol.
+include::config/pull.txt[]
-* `1` - the original wire protocol with the addition of a version string
- in the initial response from the server.
+include::config/push.txt[]
-* `2` - link:technical/protocol-v2.html[wire protocol version 2].
+include::config/rebase.txt[]
---
+include::config/receive.txt[]
-include::pull-config.txt[]
+include::config/remote.txt[]
-include::push-config.txt[]
+include::config/remotes.txt[]
-include::rebase-config.txt[]
+include::config/repack.txt[]
-include::receive-config.txt[]
+include::config/rerere.txt[]
-remote.pushDefault::
- The remote to push to by default. Overrides
- `branch.<name>.remote` for all branches, and is overridden by
- `branch.<name>.pushRemote` for specific branches.
+include::config/reset.txt[]
-remote.<name>.url::
- The URL of a remote repository. See linkgit:git-fetch[1] or
- linkgit:git-push[1].
+include::config/sendemail.txt[]
-remote.<name>.pushurl::
- The push URL of a remote repository. See linkgit:git-push[1].
+include::config/sequencer.txt[]
-remote.<name>.proxy::
- For remotes that require curl (http, https and ftp), the URL to
- the proxy to use for that remote. Set to the empty string to
- disable proxying for that remote.
+include::config/showbranch.txt[]
-remote.<name>.proxyAuthMethod::
- For remotes that require curl (http, https and ftp), the method to use for
- authenticating against the proxy in use (probably set in
- `remote.<name>.proxy`). See `http.proxyAuthMethod`.
+include::config/splitindex.txt[]
-remote.<name>.fetch::
- The default set of "refspec" for linkgit:git-fetch[1]. See
- linkgit:git-fetch[1].
+include::config/ssh.txt[]
-remote.<name>.push::
- The default set of "refspec" for linkgit:git-push[1]. See
- linkgit:git-push[1].
+include::config/status.txt[]
-remote.<name>.mirror::
- If true, pushing to this remote will automatically behave
- as if the `--mirror` option was given on the command line.
+include::config/stash.txt[]
-remote.<name>.skipDefaultUpdate::
- If true, this remote will be skipped by default when updating
- using linkgit:git-fetch[1] or the `update` subcommand of
- linkgit:git-remote[1].
+include::config/submodule.txt[]
-remote.<name>.skipFetchAll::
- If true, this remote will be skipped by default when updating
- using linkgit:git-fetch[1] or the `update` subcommand of
- linkgit:git-remote[1].
+include::config/tag.txt[]
-remote.<name>.receivepack::
- The default program to execute on the remote side when pushing. See
- option --receive-pack of linkgit:git-push[1].
+include::config/transfer.txt[]
-remote.<name>.uploadpack::
- The default program to execute on the remote side when fetching. See
- option --upload-pack of linkgit:git-fetch-pack[1].
+include::config/uploadarchive.txt[]
-remote.<name>.tagOpt::
- Setting this value to --no-tags disables automatic tag following when
- fetching from remote <name>. Setting it to --tags will fetch every
- tag from remote <name>, even if they are not reachable from remote
- branch heads. Passing these flags directly to linkgit:git-fetch[1] can
- override this setting. See options --tags and --no-tags of
- linkgit:git-fetch[1].
+include::config/uploadpack.txt[]
-remote.<name>.vcs::
- Setting this to a value <vcs> will cause Git to interact with
- the remote with the git-remote-<vcs> helper.
+include::config/url.txt[]
-remote.<name>.prune::
- When set to true, fetching from this remote by default will also
- remove any remote-tracking references that no longer exist on the
- remote (as if the `--prune` option was given on the command line).
- Overrides `fetch.prune` settings, if any.
+include::config/user.txt[]
-remote.<name>.pruneTags::
- When set to true, fetching from this remote by default will also
- remove any local tags that no longer exist on the remote if pruning
- is activated in general via `remote.<name>.prune`, `fetch.prune` or
- `--prune`. Overrides `fetch.pruneTags` settings, if any.
-+
-See also `remote.<name>.prune` and the PRUNING section of
-linkgit:git-fetch[1].
-
-remotes.<group>::
- The list of remotes which are fetched by "git remote update
- <group>". See linkgit:git-remote[1].
-
-repack.useDeltaBaseOffset::
- By default, linkgit:git-repack[1] creates packs that use
- delta-base offset. If you need to share your repository with
- Git older than version 1.4.4, either directly or via a dumb
- protocol such as http, then you need to set this option to
- "false" and repack. Access from old Git versions over the
- native protocol are unaffected by this option.
-
-repack.packKeptObjects::
- If set to true, makes `git repack` act as if
- `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
- details. Defaults to `false` normally, but `true` if a bitmap
- index is being written (either via `--write-bitmap-index` or
- `repack.writeBitmaps`).
-
-repack.useDeltaIslands::
- If set to true, makes `git repack` act as if `--delta-islands`
- was passed. Defaults to `false`.
-
-repack.writeBitmaps::
- When true, git will write a bitmap index when packing all
- objects to disk (e.g., when `git repack -a` is run). This
- index can speed up the "counting objects" phase of subsequent
- packs created for clones and fetches, at the cost of some disk
- space and extra time spent on the initial repack. This has
- no effect if multiple packfiles are created.
- Defaults to false.
-
-rerere.autoUpdate::
- When set to true, `git-rerere` updates the index with the
- resulting contents after it cleanly resolves conflicts using
- previously recorded resolution. Defaults to false.
-
-rerere.enabled::
- Activate recording of resolved conflicts, so that identical
- conflict hunks can be resolved automatically, should they be
- encountered again. By default, linkgit:git-rerere[1] is
- enabled if there is an `rr-cache` directory under the
- `$GIT_DIR`, e.g. if "rerere" was previously used in the
- repository.
-
-reset.quiet::
- When set to true, 'git reset' will default to the '--quiet' option.
-
-include::sendemail-config.txt[]
-
-sequence.editor::
- Text editor used by `git rebase -i` for editing the rebase instruction file.
- The value is meant to be interpreted by the shell when it is used.
- It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
- When not configured the default commit message editor is used instead.
-
-showBranch.default::
- The default set of branches for linkgit:git-show-branch[1].
- See linkgit:git-show-branch[1].
-
-splitIndex.maxPercentChange::
- When the split index feature is used, this specifies the
- percent of entries the split index can contain compared to the
- total number of entries in both the split index and the shared
- index before a new shared index is written.
- The value should be between 0 and 100. If the value is 0 then
- a new shared index is always written, if it is 100 a new
- shared index is never written.
- By default the value is 20, so a new shared index is written
- if the number of entries in the split index would be greater
- than 20 percent of the total number of entries.
- See linkgit:git-update-index[1].
-
-splitIndex.sharedIndexExpire::
- When the split index feature is used, shared index files that
- were not modified since the time this variable specifies will
- be removed when a new shared index file is created. The value
- "now" expires all entries immediately, and "never" suppresses
- expiration altogether.
- The default value is "2.weeks.ago".
- Note that a shared index file is considered modified (for the
- purpose of expiration) each time a new split-index file is
- either created based on it or read from it.
- See linkgit:git-update-index[1].
+include::config/versionsort.txt[]
-include::config/ssh.txt[]
+include::config/web.txt[]
-status.relativePaths::
- By default, linkgit:git-status[1] shows paths relative to the
- current directory. Setting this variable to `false` shows paths
- relative to the repository root (this was the default for Git
- prior to v1.5.4).
-
-status.short::
- Set to true to enable --short by default in linkgit:git-status[1].
- The option --no-short takes precedence over this variable.
-
-status.branch::
- Set to true to enable --branch by default in linkgit:git-status[1].
- The option --no-branch takes precedence over this variable.
-
-status.displayCommentPrefix::
- If set to true, linkgit:git-status[1] will insert a comment
- prefix before each output line (starting with
- `core.commentChar`, i.e. `#` by default). This was the
- behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
- Defaults to false.
-
-status.renameLimit::
- The number of files to consider when performing rename detection
- in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
- the value of diff.renameLimit.
-
-status.renames::
- Whether and how Git detects renames in linkgit:git-status[1] and
- linkgit:git-commit[1] . If set to "false", rename detection is
- disabled. If set to "true", basic rename detection is enabled.
- If set to "copies" or "copy", Git will detect copies, as well.
- Defaults to the value of diff.renames.
-
-status.showStash::
- If set to true, linkgit:git-status[1] will display the number of
- entries currently stashed away.
- Defaults to false.
-
-status.showUntrackedFiles::
- By default, linkgit:git-status[1] and linkgit:git-commit[1] show
- files which are not currently tracked by Git. Directories which
- contain only untracked files, are shown with the directory name
- only. Showing untracked files means that Git needs to lstat() all
- the files in the whole repository, which might be slow on some
- systems. So, this variable controls how the commands displays
- the untracked files. Possible values are:
-+
---
-* `no` - Show no untracked files.
-* `normal` - Show untracked files and directories.
-* `all` - Show also individual files in untracked directories.
---
-+
-If this variable is not specified, it defaults to 'normal'.
-This variable can be overridden with the -u|--untracked-files option
-of linkgit:git-status[1] and linkgit:git-commit[1].
-
-status.submoduleSummary::
- Defaults to false.
- If this is set to a non zero number or true (identical to -1 or an
- unlimited number), the submodule summary will be enabled and a
- summary of commits for modified submodules will be shown (see
- --summary-limit option of linkgit:git-submodule[1]). Please note
- that the summary output command will be suppressed for all
- submodules when `diff.ignoreSubmodules` is set to 'all' or only
- for those submodules where `submodule.<name>.ignore=all`. The only
- exception to that rule is that status and commit will show staged
- submodule changes. To
- also view the summary for ignored submodules you can either use
- the --ignore-submodules=dirty command-line option or the 'git
- submodule summary' command, which shows a similar output but does
- not honor these settings.
-
-stash.showPatch::
- If this is set to true, the `git stash show` command without an
- option will show the stash entry in patch form. Defaults to false.
- See description of 'show' command in linkgit:git-stash[1].
-
-stash.showStat::
- If this is set to true, the `git stash show` command without an
- option will show diffstat of the stash entry. Defaults to true.
- See description of 'show' command in linkgit:git-stash[1].
-
-include::submodule-config.txt[]
-
-tag.forceSignAnnotated::
- A boolean to specify whether annotated tags created should be GPG signed.
- If `--annotate` is specified on the command line, it takes
- precedence over this option.
-
-tag.sort::
- This variable controls the sort ordering of tags when displayed by
- linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
- value of this variable will be used as the default.
-
-tar.umask::
- This variable can be used to restrict the permission bits of
- tar archive entries. The default is 0002, which turns off the
- world write bit. The special value "user" indicates that the
- archiving user's umask will be used instead. See umask(2) and
- linkgit:git-archive[1].
-
-transfer.fsckObjects::
- When `fetch.fsckObjects` or `receive.fsckObjects` are
- not set, the value of this variable is used instead.
- Defaults to false.
-+
-When set, the fetch or receive will abort in the case of a malformed
-object or a link to a nonexistent object. In addition, various other
-issues are checked for, including legacy issues (see `fsck.<msg-id>`),
-and potential security issues like the existence of a `.GIT` directory
-or a malicious `.gitmodules` file (see the release notes for v2.2.1
-and v2.17.1 for details). Other sanity and security checks may be
-added in future releases.
-+
-On the receiving side, failing fsckObjects will make those objects
-unreachable, see "QUARANTINE ENVIRONMENT" in
-linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
-instead be left unreferenced in the repository.
-+
-Due to the non-quarantine nature of the `fetch.fsckObjects`
-implementation it can not be relied upon to leave the object store
-clean like `receive.fsckObjects` can.
-+
-As objects are unpacked they're written to the object store, so there
-can be cases where malicious objects get introduced even though the
-"fetch" failed, only to have a subsequent "fetch" succeed because only
-new incoming objects are checked, not those that have already been
-written to the object store. That difference in behavior should not be
-relied upon. In the future, such objects may be quarantined for
-"fetch" as well.
-+
-For now, the paranoid need to find some way to emulate the quarantine
-environment if they'd like the same protection as "push". E.g. in the
-case of an internal mirror do the mirroring in two steps, one to fetch
-the untrusted objects, and then do a second "push" (which will use the
-quarantine) to another internal repo, and have internal clients
-consume this pushed-to repository, or embargo internal fetches and
-only allow them once a full "fsck" has run (and no new fetches have
-happened in the meantime).
-
-transfer.hideRefs::
- String(s) `receive-pack` and `upload-pack` use to decide which
- refs to omit from their initial advertisements. Use more than
- one definition to specify multiple prefix strings. A ref that is
- under the hierarchies listed in the value of this variable is
- excluded, and is hidden when responding to `git push` or `git
- fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for
- program-specific versions of this config.
-+
-You may also include a `!` in front of the ref name to negate the entry,
-explicitly exposing it, even if an earlier entry marked it as hidden.
-If you have multiple hideRefs values, later entries override earlier ones
-(and entries in more-specific config files override less-specific ones).
-+
-If a namespace is in use, the namespace prefix is stripped from each
-reference before it is matched against `transfer.hiderefs` patterns.
-For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
-the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
-is omitted from the advertisements but `refs/heads/master` and
-`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
-"have" lines. In order to match refs before stripping, add a `^` in front of
-the ref name. If you combine `!` and `^`, `!` must be specified first.
-+
-Even if you hide refs, a client may still be able to steal the target
-objects via the techniques described in the "SECURITY" section of the
-linkgit:gitnamespaces[7] man page; it's best to keep private data in a
-separate repository.
-
-transfer.unpackLimit::
- When `fetch.unpackLimit` or `receive.unpackLimit` are
- not set, the value of this variable is used instead.
- The default value is 100.
-
-uploadarchive.allowUnreachable::
- If true, allow clients to use `git archive --remote` to request
- any tree, whether reachable from the ref tips or not. See the
- discussion in the "SECURITY" section of
- linkgit:git-upload-archive[1] for more details. Defaults to
- `false`.
-
-uploadpack.hideRefs::
- This variable is the same as `transfer.hideRefs`, but applies
- only to `upload-pack` (and so affects only fetches, not pushes).
- An attempt to fetch a hidden ref by `git fetch` will fail. See
- also `uploadpack.allowTipSHA1InWant`.
-
-uploadpack.allowTipSHA1InWant::
- When `uploadpack.hideRefs` is in effect, allow `upload-pack`
- to accept a fetch request that asks for an object at the tip
- of a hidden ref (by default, such a request is rejected).
- See also `uploadpack.hideRefs`. Even if this is false, a client
- may be able to steal objects via the techniques described in the
- "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
- best to keep private data in a separate repository.
-
-uploadpack.allowReachableSHA1InWant::
- Allow `upload-pack` to accept a fetch request that asks for an
- object that is reachable from any ref tip. However, note that
- calculating object reachability is computationally expensive.
- Defaults to `false`. Even if this is false, a client may be able
- to steal objects via the techniques described in the "SECURITY"
- section of the linkgit:gitnamespaces[7] man page; it's best to
- keep private data in a separate repository.
-
-uploadpack.allowAnySHA1InWant::
- Allow `upload-pack` to accept a fetch request that asks for any
- object at all.
- Defaults to `false`.
-
-uploadpack.keepAlive::
- When `upload-pack` has started `pack-objects`, there may be a
- quiet period while `pack-objects` prepares the pack. Normally
- it would output progress information, but if `--quiet` was used
- for the fetch, `pack-objects` will output nothing at all until
- the pack data begins. Some clients and networks may consider
- the server to be hung and give up. Setting this option instructs
- `upload-pack` to send an empty keepalive packet every
- `uploadpack.keepAlive` seconds. Setting this option to 0
- disables keepalive packets entirely. The default is 5 seconds.
-
-uploadpack.packObjectsHook::
- If this option is set, when `upload-pack` would run
- `git pack-objects` to create a packfile for a client, it will
- run this shell command instead. The `pack-objects` command and
- arguments it _would_ have run (including the `git pack-objects`
- at the beginning) are appended to the shell command. The stdin
- and stdout of the hook are treated as if `pack-objects` itself
- was run. I.e., `upload-pack` will feed input intended for
- `pack-objects` to the hook, and expects a completed packfile on
- stdout.
-+
-Note that this configuration variable is ignored if it is seen in the
-repository-level config (this is a safety measure against fetching from
-untrusted repositories).
-
-uploadpack.allowFilter::
- If this option is set, `upload-pack` will support partial
- clone and partial fetch object filtering.
-
-uploadpack.allowRefInWant::
- If this option is set, `upload-pack` will support the `ref-in-want`
- feature of the protocol version 2 `fetch` command. This feature
- is intended for the benefit of load-balanced servers which may
- not have the same view of what OIDs their refs point to due to
- replication delay.
-
-url.<base>.insteadOf::
- Any URL that starts with this value will be rewritten to
- start, instead, with <base>. In cases where some site serves a
- large number of repositories, and serves them with multiple
- access methods, and some users need to use different access
- methods, this feature allows people to specify any of the
- equivalent URLs and have Git automatically rewrite the URL to
- the best alternative for the particular user, even for a
- never-before-seen repository on the site. When more than one
- insteadOf strings match a given URL, the longest match is used.
-+
-Note that any protocol restrictions will be applied to the rewritten
-URL. If the rewrite changes the URL to use a custom protocol or remote
-helper, you may need to adjust the `protocol.*.allow` config to permit
-the request. In particular, protocols you expect to use for submodules
-must be set to `always` rather than the default of `user`. See the
-description of `protocol.allow` above.
-
-url.<base>.pushInsteadOf::
- Any URL that starts with this value will not be pushed to;
- instead, it will be rewritten to start with <base>, and the
- resulting URL will be pushed to. In cases where some site serves
- a large number of repositories, and serves them with multiple
- access methods, some of which do not allow push, this feature
- allows people to specify a pull-only URL and have Git
- automatically use an appropriate URL to push, even for a
- never-before-seen repository on the site. When more than one
- pushInsteadOf strings match a given URL, the longest match is
- used. If a remote has an explicit pushurl, Git will ignore this
- setting for that remote.
-
-user.email::
- Your email address to be recorded in any newly created commits.
- Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
- `EMAIL` environment variables. See linkgit:git-commit-tree[1].
-
-user.name::
- Your full name to be recorded in any newly created commits.
- Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
- environment variables. See linkgit:git-commit-tree[1].
-
-user.useConfigOnly::
- Instruct Git to avoid trying to guess defaults for `user.email`
- and `user.name`, and instead retrieve the values only from the
- configuration. For example, if you have multiple email addresses
- and would like to use a different one for each repository, then
- with this configuration option set to `true` in the global config
- along with a name, Git will prompt you to set up an email before
- making new commits in a newly cloned repository.
- Defaults to `false`.
-
-user.signingKey::
- If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
- key you want it to automatically when creating a signed tag or
- commit, you can override the default selection with this variable.
- This option is passed unchanged to gpg's --local-user parameter,
- so you may specify a key using any method that gpg supports.
-
-versionsort.prereleaseSuffix (deprecated)::
- Deprecated alias for `versionsort.suffix`. Ignored if
- `versionsort.suffix` is set.
-
-versionsort.suffix::
- Even when version sort is used in linkgit:git-tag[1], tagnames
- with the same base version but different suffixes are still sorted
- lexicographically, resulting e.g. in prerelease tags appearing
- after the main release (e.g. "1.0-rc1" after "1.0"). This
- variable can be specified to determine the sorting order of tags
- with different suffixes.
-+
-By specifying a single suffix in this variable, any tagname containing
-that suffix will appear before the corresponding main release. E.g. if
-the variable is set to "-rc", then all "1.0-rcX" tags will appear before
-"1.0". If specified multiple times, once per suffix, then the order of
-suffixes in the configuration will determine the sorting order of tagnames
-with those suffixes. E.g. if "-pre" appears before "-rc" in the
-configuration, then all "1.0-preX" tags will be listed before any
-"1.0-rcX" tags. The placement of the main release tag relative to tags
-with various suffixes can be determined by specifying the empty suffix
-among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and
-"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
-are listed first, followed by "v4.8", then "v4.8-ckX" and finally
-"v4.8-bfsX".
-+
-If more than one suffixes match the same tagname, then that tagname will
-be sorted according to the suffix which starts at the earliest position in
-the tagname. If more than one different matching suffixes start at
-that earliest position, then that tagname will be sorted according to the
-longest of those suffixes.
-The sorting order between different suffixes is undefined if they are
-in multiple config files.
-
-web.browser::
- Specify a web browser that may be used by some commands.
- Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
- may use it.
-
-worktree.guessRemote::
- With `add`, if no branch argument, and neither of `-b` nor
- `-B` nor `--detach` are given, the command defaults to
- creating a new branch from HEAD. If `worktree.guessRemote` is
- set to true, `worktree add` tries to find a remote-tracking
- branch whose name uniquely matches the new branch name. If
- such a branch exists, it is checked out and set as "upstream"
- for the new branch. If no such match can be found, it falls
- back to creating a new branch from the current HEAD.
+include::config/worktree.txt[]