734dfebbf3
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
1955 lines
79 KiB
Plaintext
1955 lines
79 KiB
Plaintext
CONFIGURATION FILE
|
|
------------------
|
|
|
|
The Git configuration file contains a number of variables that affect
|
|
the Git commands' behavior. The `.git/config` file in each repository
|
|
is used to store the configuration for that repository, and
|
|
`$HOME/.gitconfig` is used to store a per-user configuration as
|
|
fallback values for the `.git/config` file. The file `/etc/gitconfig`
|
|
can be used to store a system-wide default configuration.
|
|
|
|
The configuration variables are used by both the Git plumbing
|
|
and the porcelains. The variables are divided into sections, wherein
|
|
the fully qualified variable name of the variable itself is the last
|
|
dot-separated segment and the section name is everything before the last
|
|
dot. The variable names are case-insensitive, allow only alphanumeric
|
|
characters and `-`, and must start with an alphabetic character. Some
|
|
variables may appear multiple times; we say then that the variable is
|
|
multivalued.
|
|
|
|
Syntax
|
|
~~~~~~
|
|
|
|
The syntax is fairly flexible and permissive; whitespaces are mostly
|
|
ignored. The '#' and ';' characters begin comments to the end of line,
|
|
blank lines are ignored.
|
|
|
|
The file consists of sections and variables. A section begins with
|
|
the name of the section in square brackets and continues until the next
|
|
section begins. Section names are case-insensitive. Only alphanumeric
|
|
characters, `-` and `.` are allowed in section names. Each variable
|
|
must belong to some section, which means that there must be a section
|
|
header before the first setting of a variable.
|
|
|
|
Sections can be further divided into subsections. To begin a subsection
|
|
put its name in double quotes, separated by space from the section name,
|
|
in the section header, like in the example below:
|
|
|
|
--------
|
|
[section "subsection"]
|
|
|
|
--------
|
|
|
|
Subsection names are case sensitive and can contain any characters except
|
|
newline and the null byte. Doublequote `"` and backslash can be included
|
|
by escaping them as `\"` and `\\`, respectively. Backslashes preceding
|
|
other characters are dropped when reading; for example, `\t` is read as
|
|
`t` and `\0` is read as `0` Section headers cannot span multiple lines.
|
|
Variables may belong directly to a section or to a given subsection. You
|
|
can have `[section]` if you have `[section "subsection"]`, but you don't
|
|
need to.
|
|
|
|
There is also a deprecated `[section.subsection]` syntax. With this
|
|
syntax, the subsection name is converted to lower-case and is also
|
|
compared case sensitively. These subsection names follow the same
|
|
restrictions as section names.
|
|
|
|
All the other lines (and the remainder of the line after the section
|
|
header) are recognized as setting variables, in the form
|
|
'name = value' (or just 'name', which is a short-hand to say that
|
|
the variable is the boolean "true").
|
|
The variable names are case-insensitive, allow only alphanumeric characters
|
|
and `-`, and must start with an alphabetic character.
|
|
|
|
A line that defines a value can be continued to the next line by
|
|
ending it with a `\`; the backquote and the end-of-line are
|
|
stripped. Leading whitespaces after 'name =', the remainder of the
|
|
line after the first comment character '#' or ';', and trailing
|
|
whitespaces of the line are discarded unless they are enclosed in
|
|
double quotes. Internal whitespaces within the value are retained
|
|
verbatim.
|
|
|
|
Inside double quotes, double quote `"` and backslash `\` characters
|
|
must be escaped: use `\"` for `"` and `\\` for `\`.
|
|
|
|
The following escape sequences (beside `\"` and `\\`) are recognized:
|
|
`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
|
|
and `\b` for backspace (BS). Other char escape sequences (including octal
|
|
escape sequences) are invalid.
|
|
|
|
|
|
Includes
|
|
~~~~~~~~
|
|
|
|
The `include` and `includeIf` sections allow you to include config
|
|
directives from another source. These sections behave identically to
|
|
each other with the exception that `includeIf` sections may be ignored
|
|
if their condition does not evaluate to true; see "Conditional includes"
|
|
below.
|
|
|
|
You can include a config file from another by setting the special
|
|
`include.path` (or `includeIf.*.path`) variable to the name of the file
|
|
to be included. The variable takes a pathname as its value, and is
|
|
subject to tilde expansion. These variables can be given multiple times.
|
|
|
|
The contents of the included file are inserted immediately, as if they
|
|
had been found at the location of the include directive. If the value of the
|
|
variable is a relative path, the path is considered to
|
|
be relative to the configuration file in which the include directive
|
|
was found. See below for examples.
|
|
|
|
Conditional includes
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
You can include a config file from another conditionally by setting a
|
|
`includeIf.<condition>.path` variable to the name of the file to be
|
|
included.
|
|
|
|
The condition starts with a keyword followed by a colon and some data
|
|
whose format and meaning depends on the keyword. Supported keywords
|
|
are:
|
|
|
|
`gitdir`::
|
|
|
|
The data that follows the keyword `gitdir:` is used as a glob
|
|
pattern. If the location of the .git directory matches the
|
|
pattern, the include condition is met.
|
|
+
|
|
The .git location may be auto-discovered, or come from `$GIT_DIR`
|
|
environment variable. If the repository is auto discovered via a .git
|
|
file (e.g. from submodules, or a linked worktree), the .git location
|
|
would be the final location where the .git directory is, not where the
|
|
.git file is.
|
|
+
|
|
The pattern can contain standard globbing wildcards and two additional
|
|
ones, `**/` and `/**`, that can match multiple path components. Please
|
|
refer to linkgit:gitignore[5] for details. For convenience:
|
|
|
|
* If the pattern starts with `~/`, `~` will be substituted with the
|
|
content of the environment variable `HOME`.
|
|
|
|
* If the pattern starts with `./`, it is replaced with the directory
|
|
containing the current config file.
|
|
|
|
* If the pattern does not start with either `~/`, `./` or `/`, `**/`
|
|
will be automatically prepended. For example, the pattern `foo/bar`
|
|
becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
|
|
|
|
* If the pattern ends with `/`, `**` will be automatically added. For
|
|
example, the pattern `foo/` becomes `foo/**`. In other words, it
|
|
matches "foo" and everything inside, recursively.
|
|
|
|
`gitdir/i`::
|
|
This is the same as `gitdir` except that matching is done
|
|
case-insensitively (e.g. on case-insensitive file sytems)
|
|
|
|
A few more notes on matching via `gitdir` and `gitdir/i`:
|
|
|
|
* Symlinks in `$GIT_DIR` are not resolved before matching.
|
|
|
|
* Both the symlink & realpath versions of paths will be matched
|
|
outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
|
|
/mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
|
|
will match.
|
|
+
|
|
This was not the case in the initial release of this feature in
|
|
v2.13.0, which only matched the realpath version. Configuration that
|
|
wants to be compatible with the initial release of this feature needs
|
|
to either specify only the realpath version, or both versions.
|
|
|
|
* Note that "../" is not special and will match literally, which is
|
|
unlikely what you want.
|
|
|
|
Example
|
|
~~~~~~~
|
|
|
|
# Core variables
|
|
[core]
|
|
; Don't trust file modes
|
|
filemode = false
|
|
|
|
# Our diff algorithm
|
|
[diff]
|
|
external = /usr/local/bin/diff-wrapper
|
|
renames = true
|
|
|
|
[branch "devel"]
|
|
remote = origin
|
|
merge = refs/heads/devel
|
|
|
|
# Proxy settings
|
|
[core]
|
|
gitProxy="ssh" for "kernel.org"
|
|
gitProxy=default-proxy ; for the rest
|
|
|
|
[include]
|
|
path = /path/to/foo.inc ; include by absolute path
|
|
path = foo.inc ; find "foo.inc" relative to the current file
|
|
path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
|
|
|
|
; include if $GIT_DIR is /path/to/foo/.git
|
|
[includeIf "gitdir:/path/to/foo/.git"]
|
|
path = /path/to/foo.inc
|
|
|
|
; include for all repositories inside /path/to/group
|
|
[includeIf "gitdir:/path/to/group/"]
|
|
path = /path/to/foo.inc
|
|
|
|
; include for all repositories inside $HOME/to/group
|
|
[includeIf "gitdir:~/to/group/"]
|
|
path = /path/to/foo.inc
|
|
|
|
; relative paths are always relative to the including
|
|
; file (if the condition is true); their location is not
|
|
; affected by the condition
|
|
[includeIf "gitdir:/path/to/group/"]
|
|
path = foo.inc
|
|
|
|
Values
|
|
~~~~~~
|
|
|
|
Values of many variables are treated as a simple string, but there
|
|
are variables that take values of specific types and there are rules
|
|
as to how to spell them.
|
|
|
|
boolean::
|
|
|
|
When a variable is said to take a boolean value, many
|
|
synonyms are accepted for 'true' and 'false'; these are all
|
|
case-insensitive.
|
|
|
|
true;; Boolean true literals are `yes`, `on`, `true`,
|
|
and `1`. Also, a variable defined without `= <value>`
|
|
is taken as true.
|
|
|
|
false;; Boolean false literals are `no`, `off`, `false`,
|
|
`0` and the empty string.
|
|
+
|
|
When converting a value to its canonical form using the `--type=bool` type
|
|
specifier, 'git config' will ensure that the output is "true" or
|
|
"false" (spelled in lowercase).
|
|
|
|
integer::
|
|
The value for many variables that specify various sizes can
|
|
be suffixed with `k`, `M`,... to mean "scale the number by
|
|
1024", "by 1024x1024", etc.
|
|
|
|
color::
|
|
The value for a variable that takes a color is a list of
|
|
colors (at most two, one for foreground and one for background)
|
|
and attributes (as many as you want), separated by spaces.
|
|
+
|
|
The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`,
|
|
`blue`, `magenta`, `cyan` and `white`. The first color given is the
|
|
foreground; the second is the background.
|
|
+
|
|
Colors may also be given as numbers between 0 and 255; these use ANSI
|
|
256-color mode (but note that not all terminals may support this). If
|
|
your terminal supports it, you may also specify 24-bit RGB values as
|
|
hex, like `#ff0ab3`.
|
|
+
|
|
The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
|
|
`italic`, and `strike` (for crossed-out or "strikethrough" letters).
|
|
The position of any attributes with respect to the colors
|
|
(before, after, or in between), doesn't matter. Specific attributes may
|
|
be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
|
|
`no-ul`, etc).
|
|
+
|
|
An empty color string produces no color effect at all. This can be used
|
|
to avoid coloring specific elements without disabling color entirely.
|
|
+
|
|
For git's pre-defined color slots, the attributes are meant to be reset
|
|
at the beginning of each item in the colored output. So setting
|
|
`color.decorate.branch` to `black` will paint that branch name in a
|
|
plain `black`, even if the previous thing on the same output line (e.g.
|
|
opening parenthesis before the list of branch names in `log --decorate`
|
|
output) is set to be painted with `bold` or some other attribute.
|
|
However, custom log formats may do more complicated and layered
|
|
coloring, and the negated forms may be useful there.
|
|
|
|
pathname::
|
|
A variable that takes a pathname value can be given a
|
|
string that begins with "`~/`" or "`~user/`", and the usual
|
|
tilde expansion happens to such a string: `~/`
|
|
is expanded to the value of `$HOME`, and `~user/` to the
|
|
specified user's home directory.
|
|
|
|
|
|
Variables
|
|
~~~~~~~~~
|
|
|
|
Note that this list is non-comprehensive and not necessarily complete.
|
|
For command-specific variables, you will find a more detailed description
|
|
in the appropriate manual page.
|
|
|
|
Other git-related tools may and do use their own variables. When
|
|
inventing new variables for use in your own tool, make sure their
|
|
names do not conflict with those that are used by Git itself and
|
|
other popular tools, and describe them in your documentation.
|
|
|
|
include::config/advice.txt[]
|
|
|
|
include::config/core.txt[]
|
|
|
|
include::config/add.txt[]
|
|
|
|
include::config/alias.txt[]
|
|
|
|
include::config/am.txt[]
|
|
|
|
include::config/apply.txt[]
|
|
|
|
include::config/blame.txt[]
|
|
|
|
include::config/branch.txt[]
|
|
|
|
include::config/browser.txt[]
|
|
|
|
include::config/checkout.txt[]
|
|
|
|
include::config/clean.txt[]
|
|
|
|
include::config/color.txt[]
|
|
|
|
include::config/column.txt[]
|
|
|
|
include::config/commit.txt[]
|
|
|
|
include::config/credential.txt[]
|
|
|
|
include::config/completion.txt[]
|
|
|
|
include::config/diff.txt[]
|
|
|
|
include::config/difftool.txt[]
|
|
|
|
include::config/fastimport.txt[]
|
|
|
|
include::config/fetch.txt[]
|
|
|
|
include::format-config.txt[]
|
|
|
|
include::config/filter.txt[]
|
|
|
|
fsck.<msg-id>::
|
|
During fsck git may find issues with legacy data which
|
|
wouldn't be generated by current versions of git, and which
|
|
wouldn't be sent over the wire if `transfer.fsckObjects` was
|
|
set. This feature is intended to support working with legacy
|
|
repositories containing such data.
|
|
+
|
|
Setting `fsck.<msg-id>` will be picked up by linkgit:git-fsck[1], but
|
|
to accept pushes of such data set `receive.fsck.<msg-id>` instead, or
|
|
to clone or fetch it set `fetch.fsck.<msg-id>`.
|
|
+
|
|
The rest of the documentation discusses `fsck.*` for brevity, but the
|
|
same applies for the corresponding `receive.fsck.*` and
|
|
`fetch.<msg-id>.*`. variables.
|
|
+
|
|
Unlike variables like `color.ui` and `core.editor` the
|
|
`receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>` variables will not
|
|
fall back on the `fsck.<msg-id>` configuration if they aren't set. To
|
|
uniformly configure the same fsck settings in different circumstances
|
|
all three of them they must all set to the same values.
|
|
+
|
|
When `fsck.<msg-id>` is set, errors can be switched to warnings and
|
|
vice versa by configuring the `fsck.<msg-id>` setting where the
|
|
`<msg-id>` is the fsck message ID and the value is one of `error`,
|
|
`warn` or `ignore`. For convenience, fsck prefixes the error/warning
|
|
with the message ID, e.g. "missingEmail: invalid author/committer line
|
|
- missing email" means that setting `fsck.missingEmail = ignore` will
|
|
hide that issue.
|
|
+
|
|
In general, it is better to enumerate existing objects with problems
|
|
with `fsck.skipList`, instead of listing the kind of breakages these
|
|
problematic objects share to be ignored, as doing the latter will
|
|
allow new instances of the same breakages go unnoticed.
|
|
+
|
|
Setting an unknown `fsck.<msg-id>` value will cause fsck to die, but
|
|
doing the same for `receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>`
|
|
will only cause git to warn.
|
|
|
|
fsck.skipList::
|
|
The path to a list of object names (i.e. one unabbreviated SHA-1 per
|
|
line) that are known to be broken in a non-fatal way and should
|
|
be ignored. On versions of Git 2.20 and later comments ('#'), empty
|
|
lines, and any leading and trailing whitespace is ignored. Everything
|
|
but a SHA-1 per line will error out on older versions.
|
|
+
|
|
This feature is useful when an established project should be accepted
|
|
despite early commits containing errors that can be safely ignored
|
|
such as invalid committer email addresses. Note: corrupt objects
|
|
cannot be skipped with this setting.
|
|
+
|
|
Like `fsck.<msg-id>` this variable has corresponding
|
|
`receive.fsck.skipList` and `fetch.fsck.skipList` variants.
|
|
+
|
|
Unlike variables like `color.ui` and `core.editor` the
|
|
`receive.fsck.skipList` and `fetch.fsck.skipList` variables will not
|
|
fall back on the `fsck.skipList` configuration if they aren't set. To
|
|
uniformly configure the same fsck settings in different circumstances
|
|
all three of them they must all set to the same values.
|
|
+
|
|
Older versions of Git (before 2.20) documented that the object names
|
|
list should be sorted. This was never a requirement, the object names
|
|
could appear in any order, but when reading the list we tracked whether
|
|
the list was sorted for the purposes of an internal binary search
|
|
implementation, which could save itself some work with an already sorted
|
|
list. Unless you had a humongous list there was no reason to go out of
|
|
your way to pre-sort the list. After Git version 2.20 a hash implementation
|
|
is used instead, so there's now no reason to pre-sort the list.
|
|
|
|
gc.aggressiveDepth::
|
|
The depth parameter used in the delta compression
|
|
algorithm used by 'git gc --aggressive'. This defaults
|
|
to 50.
|
|
|
|
gc.aggressiveWindow::
|
|
The window size parameter used in the delta compression
|
|
algorithm used by 'git gc --aggressive'. This defaults
|
|
to 250.
|
|
|
|
gc.auto::
|
|
When there are approximately more than this many loose
|
|
objects in the repository, `git gc --auto` will pack them.
|
|
Some Porcelain commands use this command to perform a
|
|
light-weight garbage collection from time to time. The
|
|
default value is 6700. Setting this to 0 disables it.
|
|
|
|
gc.autoPackLimit::
|
|
When there are more than this many packs that are not
|
|
marked with `*.keep` file in the repository, `git gc
|
|
--auto` consolidates them into one larger pack. The
|
|
default value is 50. Setting this to 0 disables it.
|
|
|
|
gc.autoDetach::
|
|
Make `git gc --auto` return immediately and run in background
|
|
if the system supports it. Default is true.
|
|
|
|
gc.bigPackThreshold::
|
|
If non-zero, all packs larger than this limit are kept when
|
|
`git gc` is run. This is very similar to `--keep-base-pack`
|
|
except that all packs that meet the threshold are kept, not
|
|
just the base pack. Defaults to zero. Common unit suffixes of
|
|
'k', 'm', or 'g' are supported.
|
|
+
|
|
Note that if the number of kept packs is more than gc.autoPackLimit,
|
|
this configuration variable is ignored, all packs except the base pack
|
|
will be repacked. After this the number of packs should go below
|
|
gc.autoPackLimit and gc.bigPackThreshold should be respected again.
|
|
|
|
gc.writeCommitGraph::
|
|
If true, then gc will rewrite the commit-graph file when
|
|
linkgit:git-gc[1] is run. When using linkgit:git-gc[1]
|
|
'--auto' the commit-graph will be updated if housekeeping is
|
|
required. Default is false. See linkgit:git-commit-graph[1]
|
|
for details.
|
|
|
|
gc.logExpiry::
|
|
If the file gc.log exists, then `git gc --auto` will print
|
|
its content and exit with status zero instead of running
|
|
unless that file is more than 'gc.logExpiry' old. Default is
|
|
"1.day". See `gc.pruneExpire` for more ways to specify its
|
|
value.
|
|
|
|
gc.packRefs::
|
|
Running `git pack-refs` in a repository renders it
|
|
unclonable by Git versions prior to 1.5.1.2 over dumb
|
|
transports such as HTTP. This variable determines whether
|
|
'git gc' runs `git pack-refs`. This can be set to `notbare`
|
|
to enable it within all non-bare repos or it can be set to a
|
|
boolean value. The default is `true`.
|
|
|
|
gc.pruneExpire::
|
|
When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.
|
|
Override the grace period with this config variable. The value
|
|
"now" may be used to disable this grace period and always prune
|
|
unreachable objects immediately, or "never" may be used to
|
|
suppress pruning. This feature helps prevent corruption when
|
|
'git gc' runs concurrently with another process writing to the
|
|
repository; see the "NOTES" section of linkgit:git-gc[1].
|
|
|
|
gc.worktreePruneExpire::
|
|
When 'git gc' is run, it calls
|
|
'git worktree prune --expire 3.months.ago'.
|
|
This config variable can be used to set a different grace
|
|
period. The value "now" may be used to disable the grace
|
|
period and prune `$GIT_DIR/worktrees` immediately, or "never"
|
|
may be used to suppress pruning.
|
|
|
|
gc.reflogExpire::
|
|
gc.<pattern>.reflogExpire::
|
|
'git reflog expire' removes reflog entries older than
|
|
this time; defaults to 90 days. The value "now" expires all
|
|
entries immediately, and "never" suppresses expiration
|
|
altogether. With "<pattern>" (e.g.
|
|
"refs/stash") in the middle the setting applies only to
|
|
the refs that match the <pattern>.
|
|
|
|
gc.reflogExpireUnreachable::
|
|
gc.<pattern>.reflogExpireUnreachable::
|
|
'git reflog expire' removes reflog entries older than
|
|
this time and are not reachable from the current tip;
|
|
defaults to 30 days. The value "now" expires all entries
|
|
immediately, and "never" suppresses expiration altogether.
|
|
With "<pattern>" (e.g. "refs/stash")
|
|
in the middle, the setting applies only to the refs that
|
|
match the <pattern>.
|
|
|
|
gc.rerereResolved::
|
|
Records of conflicted merge you resolved earlier are
|
|
kept for this many days when 'git rerere gc' is run.
|
|
You can also use more human-readable "1.month.ago", etc.
|
|
The default is 60 days. See linkgit:git-rerere[1].
|
|
|
|
gc.rerereUnresolved::
|
|
Records of conflicted merge you have not resolved are
|
|
kept for this many days when 'git rerere gc' is run.
|
|
You can also use more human-readable "1.month.ago", etc.
|
|
The default is 15 days. See linkgit:git-rerere[1].
|
|
|
|
include::gitcvs-config.txt[]
|
|
|
|
gitweb.category::
|
|
gitweb.description::
|
|
gitweb.owner::
|
|
gitweb.url::
|
|
See linkgit:gitweb[1] for description.
|
|
|
|
gitweb.avatar::
|
|
gitweb.blame::
|
|
gitweb.grep::
|
|
gitweb.highlight::
|
|
gitweb.patches::
|
|
gitweb.pickaxe::
|
|
gitweb.remote_heads::
|
|
gitweb.showSizes::
|
|
gitweb.snapshot::
|
|
See linkgit:gitweb.conf[5] for description.
|
|
|
|
grep.lineNumber::
|
|
If set to true, enable `-n` option by default.
|
|
|
|
grep.column::
|
|
If set to true, enable the `--column` option by default.
|
|
|
|
grep.patternType::
|
|
Set the default matching behavior. Using a value of 'basic', 'extended',
|
|
'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`,
|
|
`--fixed-strings`, or `--perl-regexp` option accordingly, while the
|
|
value 'default' will return to the default matching behavior.
|
|
|
|
grep.extendedRegexp::
|
|
If set to true, enable `--extended-regexp` option by default. This
|
|
option is ignored when the `grep.patternType` option is set to a value
|
|
other than 'default'.
|
|
|
|
grep.threads::
|
|
Number of grep worker threads to use.
|
|
See `grep.threads` in linkgit:git-grep[1] for more information.
|
|
|
|
grep.fallbackToNoIndex::
|
|
If set to true, fall back to git grep --no-index if git grep
|
|
is executed outside of a git repository. Defaults to false.
|
|
|
|
gpg.program::
|
|
Use this custom program instead of "`gpg`" found on `$PATH` when
|
|
making or verifying a PGP signature. The program must support the
|
|
same command-line interface as GPG, namely, to verify a detached
|
|
signature, "`gpg --verify $file - <$signature`" is run, and the
|
|
program is expected to signal a good signature by exiting with
|
|
code 0, and to generate an ASCII-armored detached signature, the
|
|
standard input of "`gpg -bsau $key`" is fed with the contents to be
|
|
signed, and the program is expected to send the result to its
|
|
standard output.
|
|
|
|
gpg.format::
|
|
Specifies which key format to use when signing with `--gpg-sign`.
|
|
Default is "openpgp" and another possible value is "x509".
|
|
|
|
gpg.<format>.program::
|
|
Use this to customize the program used for the signing format you
|
|
chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still
|
|
be used as a legacy synonym for `gpg.openpgp.program`. The default
|
|
value for `gpg.x509.program` is "gpgsm".
|
|
|
|
include::gui-config.txt[]
|
|
|
|
guitool.<name>.cmd::
|
|
Specifies the shell command line to execute when the corresponding item
|
|
of the linkgit:git-gui[1] `Tools` menu is invoked. This option is
|
|
mandatory for every tool. The command is executed from the root of
|
|
the working directory, and in the environment it receives the name of
|
|
the tool as `GIT_GUITOOL`, the name of the currently selected file as
|
|
'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if
|
|
the head is detached, 'CUR_BRANCH' is empty).
|
|
|
|
guitool.<name>.needsFile::
|
|
Run the tool only if a diff is selected in the GUI. It guarantees
|
|
that 'FILENAME' is not empty.
|
|
|
|
guitool.<name>.noConsole::
|
|
Run the command silently, without creating a window to display its
|
|
output.
|
|
|
|
guitool.<name>.noRescan::
|
|
Don't rescan the working directory for changes after the tool
|
|
finishes execution.
|
|
|
|
guitool.<name>.confirm::
|
|
Show a confirmation dialog before actually running the tool.
|
|
|
|
guitool.<name>.argPrompt::
|
|
Request a string argument from the user, and pass it to the tool
|
|
through the `ARGS` environment variable. Since requesting an
|
|
argument implies confirmation, the 'confirm' option has no effect
|
|
if this is enabled. If the option is set to 'true', 'yes', or '1',
|
|
the dialog uses a built-in generic prompt; otherwise the exact
|
|
value of the variable is used.
|
|
|
|
guitool.<name>.revPrompt::
|
|
Request a single valid revision from the user, and set the
|
|
`REVISION` environment variable. In other aspects this option
|
|
is similar to 'argPrompt', and can be used together with it.
|
|
|
|
guitool.<name>.revUnmerged::
|
|
Show only unmerged branches in the 'revPrompt' subdialog.
|
|
This is useful for tools similar to merge or rebase, but not
|
|
for things like checkout or reset.
|
|
|
|
guitool.<name>.title::
|
|
Specifies the title to use for the prompt dialog. The default
|
|
is the tool name.
|
|
|
|
guitool.<name>.prompt::
|
|
Specifies the general prompt string to display at the top of
|
|
the dialog, before subsections for 'argPrompt' and 'revPrompt'.
|
|
The default value includes the actual command.
|
|
|
|
help.browser::
|
|
Specify the browser that will be used to display help in the
|
|
'web' format. See linkgit:git-help[1].
|
|
|
|
help.format::
|
|
Override the default help format used by linkgit:git-help[1].
|
|
Values 'man', 'info', 'web' and 'html' are supported. 'man' is
|
|
the default. 'web' and 'html' are the same.
|
|
|
|
help.autoCorrect::
|
|
Automatically correct and execute mistyped commands after
|
|
waiting for the given number of deciseconds (0.1 sec). If more
|
|
than one command can be deduced from the entered text, nothing
|
|
will be executed. If the value of this option is negative,
|
|
the corrected command will be executed immediately. If the
|
|
value is 0 - the command will be just shown but not executed.
|
|
This is the default.
|
|
|
|
help.htmlPath::
|
|
Specify the path where the HTML documentation resides. File system paths
|
|
and URLs are supported. HTML pages will be prefixed with this path when
|
|
help is displayed in the 'web' format. This defaults to the documentation
|
|
path of your Git installation.
|
|
|
|
http.proxy::
|
|
Override the HTTP proxy, normally configured using the 'http_proxy',
|
|
'https_proxy', and 'all_proxy' environment variables (see `curl(1)`). In
|
|
addition to the syntax understood by curl, it is possible to specify a
|
|
proxy string with a user name but no password, in which case git will
|
|
attempt to acquire one in the same way it does for other credentials. See
|
|
linkgit:gitcredentials[7] for more information. The syntax thus is
|
|
'[protocol://][user[:password]@]proxyhost[:port]'. This can be overridden
|
|
on a per-remote basis; see remote.<name>.proxy
|
|
|
|
http.proxyAuthMethod::
|
|
Set the method with which to authenticate against the HTTP proxy. This
|
|
only takes effect if the configured proxy string contains a user name part
|
|
(i.e. is of the form 'user@host' or 'user@host:port'). This can be
|
|
overridden on a per-remote basis; see `remote.<name>.proxyAuthMethod`.
|
|
Both can be overridden by the `GIT_HTTP_PROXY_AUTHMETHOD` environment
|
|
variable. Possible values are:
|
|
+
|
|
--
|
|
* `anyauth` - Automatically pick a suitable authentication method. It is
|
|
assumed that the proxy answers an unauthenticated request with a 407
|
|
status code and one or more Proxy-authenticate headers with supported
|
|
authentication methods. This is the default.
|
|
* `basic` - HTTP Basic authentication
|
|
* `digest` - HTTP Digest authentication; this prevents the password from being
|
|
transmitted to the proxy in clear text
|
|
* `negotiate` - GSS-Negotiate authentication (compare the --negotiate option
|
|
of `curl(1)`)
|
|
* `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`)
|
|
--
|
|
|
|
http.emptyAuth::
|
|
Attempt authentication without seeking a username or password. This
|
|
can be used to attempt GSS-Negotiate authentication without specifying
|
|
a username in the URL, as libcurl normally requires a username for
|
|
authentication.
|
|
|
|
http.delegation::
|
|
Control GSSAPI credential delegation. The delegation is disabled
|
|
by default in libcurl since version 7.21.7. Set parameter to tell
|
|
the server what it is allowed to delegate when it comes to user
|
|
credentials. Used with GSS/kerberos. Possible values are:
|
|
+
|
|
--
|
|
* `none` - Don't allow any delegation.
|
|
* `policy` - Delegates if and only if the OK-AS-DELEGATE flag is set in the
|
|
Kerberos service ticket, which is a matter of realm policy.
|
|
* `always` - Unconditionally allow the server to delegate.
|
|
--
|
|
|
|
|
|
http.extraHeader::
|
|
Pass an additional HTTP header when communicating with a server. If
|
|
more than one such entry exists, all of them are added as extra
|
|
headers. To allow overriding the settings inherited from the system
|
|
config, an empty value will reset the extra headers to the empty list.
|
|
|
|
http.cookieFile::
|
|
The pathname of a file containing previously stored cookie lines,
|
|
which should be used
|
|
in the Git http session, if they match the server. The file format
|
|
of the file to read cookies from should be plain HTTP headers or
|
|
the Netscape/Mozilla cookie file format (see `curl(1)`).
|
|
NOTE that the file specified with http.cookieFile is used only as
|
|
input unless http.saveCookies is set.
|
|
|
|
http.saveCookies::
|
|
If set, store cookies received during requests to the file specified by
|
|
http.cookieFile. Has no effect if http.cookieFile is unset.
|
|
|
|
http.sslVersion::
|
|
The SSL version to use when negotiating an SSL connection, if you
|
|
want to force the default. The available and default version
|
|
depend on whether libcurl was built against NSS or OpenSSL and the
|
|
particular configuration of the crypto library in use. Internally
|
|
this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl
|
|
documentation for more details on the format of this option and
|
|
for the ssl version supported. Actually the possible values of
|
|
this option are:
|
|
|
|
- sslv2
|
|
- sslv3
|
|
- tlsv1
|
|
- tlsv1.0
|
|
- tlsv1.1
|
|
- tlsv1.2
|
|
- tlsv1.3
|
|
|
|
+
|
|
Can be overridden by the `GIT_SSL_VERSION` environment variable.
|
|
To force git to use libcurl's default ssl version and ignore any
|
|
explicit http.sslversion option, set `GIT_SSL_VERSION` to the
|
|
empty string.
|
|
|
|
http.sslCipherList::
|
|
A list of SSL ciphers to use when negotiating an SSL connection.
|
|
The available ciphers depend on whether libcurl was built against
|
|
NSS or OpenSSL and the particular configuration of the crypto
|
|
library in use. Internally this sets the 'CURLOPT_SSL_CIPHER_LIST'
|
|
option; see the libcurl documentation for more details on the format
|
|
of this list.
|
|
+
|
|
Can be overridden by the `GIT_SSL_CIPHER_LIST` environment variable.
|
|
To force git to use libcurl's default cipher list and ignore any
|
|
explicit http.sslCipherList option, set `GIT_SSL_CIPHER_LIST` to the
|
|
empty string.
|
|
|
|
http.sslVerify::
|
|
Whether to verify the SSL certificate when fetching or pushing
|
|
over HTTPS. Defaults to true. Can be overridden by the
|
|
`GIT_SSL_NO_VERIFY` environment variable.
|
|
|
|
http.sslCert::
|
|
File containing the SSL certificate when fetching or pushing
|
|
over HTTPS. Can be overridden by the `GIT_SSL_CERT` environment
|
|
variable.
|
|
|
|
http.sslKey::
|
|
File containing the SSL private key when fetching or pushing
|
|
over HTTPS. Can be overridden by the `GIT_SSL_KEY` environment
|
|
variable.
|
|
|
|
http.sslCertPasswordProtected::
|
|
Enable Git's password prompt for the SSL certificate. Otherwise
|
|
OpenSSL will prompt the user, possibly many times, if the
|
|
certificate or private key is encrypted. Can be overridden by the
|
|
`GIT_SSL_CERT_PASSWORD_PROTECTED` environment variable.
|
|
|
|
http.sslCAInfo::
|
|
File containing the certificates to verify the peer with when
|
|
fetching or pushing over HTTPS. Can be overridden by the
|
|
`GIT_SSL_CAINFO` environment variable.
|
|
|
|
http.sslCAPath::
|
|
Path containing files with the CA certificates to verify the peer
|
|
with when fetching or pushing over HTTPS. Can be overridden
|
|
by the `GIT_SSL_CAPATH` environment variable.
|
|
|
|
http.sslBackend::
|
|
Name of the SSL backend to use (e.g. "openssl" or "schannel").
|
|
This option is ignored if cURL lacks support for choosing the SSL
|
|
backend at runtime.
|
|
|
|
http.schannelCheckRevoke::
|
|
Used to enforce or disable certificate revocation checks in cURL
|
|
when http.sslBackend is set to "schannel". Defaults to `true` if
|
|
unset. Only necessary to disable this if Git consistently errors
|
|
and the message is about checking the revocation status of a
|
|
certificate. This option is ignored if cURL lacks support for
|
|
setting the relevant SSL option at runtime.
|
|
|
|
http.schannelUseSSLCAInfo::
|
|
As of cURL v7.60.0, the Secure Channel backend can use the
|
|
certificate bundle provided via `http.sslCAInfo`, but that would
|
|
override the Windows Certificate Store. Since this is not desirable
|
|
by default, Git will tell cURL not to use that bundle by default
|
|
when the `schannel` backend was configured via `http.sslBackend`,
|
|
unless `http.schannelUseSSLCAInfo` overrides this behavior.
|
|
|
|
http.pinnedpubkey::
|
|
Public key of the https service. It may either be the filename of
|
|
a PEM or DER encoded public key file or a string starting with
|
|
'sha256//' followed by the base64 encoded sha256 hash of the
|
|
public key. See also libcurl 'CURLOPT_PINNEDPUBLICKEY'. git will
|
|
exit with an error if this option is set but not supported by
|
|
cURL.
|
|
|
|
http.sslTry::
|
|
Attempt to use AUTH SSL/TLS and encrypted data transfers
|
|
when connecting via regular FTP protocol. This might be needed
|
|
if the FTP server requires it for security reasons or you wish
|
|
to connect securely whenever remote FTP server supports it.
|
|
Default is false since it might trigger certificate verification
|
|
errors on misconfigured servers.
|
|
|
|
http.maxRequests::
|
|
How many HTTP requests to launch in parallel. Can be overridden
|
|
by the `GIT_HTTP_MAX_REQUESTS` environment variable. Default is 5.
|
|
|
|
http.minSessions::
|
|
The number of curl sessions (counted across slots) to be kept across
|
|
requests. They will not be ended with curl_easy_cleanup() until
|
|
http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this
|
|
value will be capped at 1. Defaults to 1.
|
|
|
|
http.postBuffer::
|
|
Maximum size in bytes of the buffer used by smart HTTP
|
|
transports when POSTing data to the remote system.
|
|
For requests larger than this buffer size, HTTP/1.1 and
|
|
Transfer-Encoding: chunked is used to avoid creating a
|
|
massive pack file locally. Default is 1 MiB, which is
|
|
sufficient for most requests.
|
|
|
|
http.lowSpeedLimit, http.lowSpeedTime::
|
|
If the HTTP transfer speed is less than 'http.lowSpeedLimit'
|
|
for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
|
|
Can be overridden by the `GIT_HTTP_LOW_SPEED_LIMIT` and
|
|
`GIT_HTTP_LOW_SPEED_TIME` environment variables.
|
|
|
|
http.noEPSV::
|
|
A boolean which disables using of EPSV ftp command by curl.
|
|
This can helpful with some "poor" ftp servers which don't
|
|
support EPSV mode. Can be overridden by the `GIT_CURL_FTP_NO_EPSV`
|
|
environment variable. Default is false (curl will use EPSV).
|
|
|
|
http.userAgent::
|
|
The HTTP USER_AGENT string presented to an HTTP server. The default
|
|
value represents the version of the client Git such as git/1.7.1.
|
|
This option allows you to override this value to a more common value
|
|
such as Mozilla/4.0. This may be necessary, for instance, if
|
|
connecting through a firewall that restricts HTTP connections to a set
|
|
of common USER_AGENT strings (but not including those like git/1.7.1).
|
|
Can be overridden by the `GIT_HTTP_USER_AGENT` environment variable.
|
|
|
|
http.followRedirects::
|
|
Whether git should follow HTTP redirects. If set to `true`, git
|
|
will transparently follow any redirect issued by a server it
|
|
encounters. If set to `false`, git will treat all redirects as
|
|
errors. If set to `initial`, git will follow redirects only for
|
|
the initial request to a remote, but not for subsequent
|
|
follow-up HTTP requests. Since git uses the redirected URL as
|
|
the base for the follow-up requests, this is generally
|
|
sufficient. The default is `initial`.
|
|
|
|
http.<url>.*::
|
|
Any of the http.* options above can be applied selectively to some URLs.
|
|
For a config key to match a URL, each element of the config key is
|
|
compared to that of the URL, in the following order:
|
|
+
|
|
--
|
|
. Scheme (e.g., `https` in `https://example.com/`). This field
|
|
must match exactly between the config key and the URL.
|
|
|
|
. Host/domain name (e.g., `example.com` in `https://example.com/`).
|
|
This field must match between the config key and the URL. It is
|
|
possible to specify a `*` as part of the host name to match all subdomains
|
|
at this level. `https://*.example.com/` for example would match
|
|
`https://foo.example.com/`, but not `https://foo.bar.example.com/`.
|
|
|
|
. Port number (e.g., `8080` in `http://example.com:8080/`).
|
|
This field must match exactly between the config key and the URL.
|
|
Omitted port numbers are automatically converted to the correct
|
|
default for the scheme before matching.
|
|
|
|
. Path (e.g., `repo.git` in `https://example.com/repo.git`). The
|
|
path field of the config key must match the path field of the URL
|
|
either exactly or as a prefix of slash-delimited path elements. This means
|
|
a config key with path `foo/` matches URL path `foo/bar`. A prefix can only
|
|
match on a slash (`/`) boundary. Longer matches take precedence (so a config
|
|
key with path `foo/bar` is a better match to URL path `foo/bar` than a config
|
|
key with just path `foo/`).
|
|
|
|
. User name (e.g., `user` in `https://user@example.com/repo.git`). If
|
|
the config key has a user name it must match the user name in the
|
|
URL exactly. If the config key does not have a user name, that
|
|
config key will match a URL with any user name (including none),
|
|
but at a lower precedence than a config key with a user name.
|
|
--
|
|
+
|
|
The list above is ordered by decreasing precedence; a URL that matches
|
|
a config key's path is preferred to one that matches its user name. For example,
|
|
if the URL is `https://user@example.com/foo/bar` a config key match of
|
|
`https://example.com/foo` will be preferred over a config key match of
|
|
`https://user@example.com`.
|
|
+
|
|
All URLs are normalized before attempting any matching (the password part,
|
|
if embedded in the URL, is always ignored for matching purposes) so that
|
|
equivalent URLs that are simply spelled differently will match properly.
|
|
Environment variable settings always override any matches. The URLs that are
|
|
matched against are those given directly to Git commands. This means any URLs
|
|
visited as a result of a redirection do not participate in matching.
|
|
|
|
ssh.variant::
|
|
By default, Git determines the command line arguments to use
|
|
based on the basename of the configured SSH command (configured
|
|
using the environment variable `GIT_SSH` or `GIT_SSH_COMMAND` or
|
|
the config setting `core.sshCommand`). If the basename is
|
|
unrecognized, Git will attempt to detect support of OpenSSH
|
|
options by first invoking the configured SSH command with the
|
|
`-G` (print configuration) option and will subsequently use
|
|
OpenSSH options (if that is successful) or no options besides
|
|
the host and remote command (if it fails).
|
|
+
|
|
The config variable `ssh.variant` can be set to override this detection.
|
|
Valid values are `ssh` (to use OpenSSH options), `plink`, `putty`,
|
|
`tortoiseplink`, `simple` (no options except the host and remote command).
|
|
The default auto-detection can be explicitly requested using the value
|
|
`auto`. Any other value is treated as `ssh`. This setting can also be
|
|
overridden via the environment variable `GIT_SSH_VARIANT`.
|
|
+
|
|
The current command-line parameters used for each variant are as
|
|
follows:
|
|
+
|
|
--
|
|
|
|
* `ssh` - [-p port] [-4] [-6] [-o option] [username@]host command
|
|
|
|
* `simple` - [username@]host command
|
|
|
|
* `plink` or `putty` - [-P port] [-4] [-6] [username@]host command
|
|
|
|
* `tortoiseplink` - [-P port] [-4] [-6] -batch [username@]host command
|
|
|
|
--
|
|
+
|
|
Except for the `simple` variant, command-line parameters are likely to
|
|
change as git gains new features.
|
|
|
|
i18n.commitEncoding::
|
|
Character encoding the commit messages are stored in; Git itself
|
|
does not care per se, but this information is necessary e.g. when
|
|
importing commits from emails or in the gitk graphical history
|
|
browser (and possibly at other places in the future or in other
|
|
porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
|
|
|
|
i18n.logOutputEncoding::
|
|
Character encoding the commit messages are converted to when
|
|
running 'git log' and friends.
|
|
|
|
imap::
|
|
The configuration variables in the 'imap' section are described
|
|
in linkgit:git-imap-send[1].
|
|
|
|
index.threads::
|
|
Specifies the number of threads to spawn when loading the index.
|
|
This is meant to reduce index load time on multiprocessor machines.
|
|
Specifying 0 or 'true' will cause Git to auto-detect the number of
|
|
CPU's and set the number of threads accordingly. Specifying 1 or
|
|
'false' will disable multithreading. Defaults to 'true'.
|
|
|
|
index.version::
|
|
Specify the version with which new index files should be
|
|
initialized. This does not affect existing repositories.
|
|
|
|
init.templateDir::
|
|
Specify the directory from which templates will be copied.
|
|
(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
|
|
|
|
instaweb.browser::
|
|
Specify the program that will be used to browse your working
|
|
repository in gitweb. See linkgit:git-instaweb[1].
|
|
|
|
instaweb.httpd::
|
|
The HTTP daemon command-line to start gitweb on your working
|
|
repository. See linkgit:git-instaweb[1].
|
|
|
|
instaweb.local::
|
|
If true the web server started by linkgit:git-instaweb[1] will
|
|
be bound to the local IP (127.0.0.1).
|
|
|
|
instaweb.modulePath::
|
|
The default module path for linkgit:git-instaweb[1] to use
|
|
instead of /usr/lib/apache2/modules. Only used if httpd
|
|
is Apache.
|
|
|
|
instaweb.port::
|
|
The port number to bind the gitweb httpd to. See
|
|
linkgit:git-instaweb[1].
|
|
|
|
interactive.singleKey::
|
|
In interactive commands, allow the user to provide one-letter
|
|
input with a single key (i.e., without hitting enter).
|
|
Currently this is used by the `--patch` mode of
|
|
linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],
|
|
linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this
|
|
setting is silently ignored if portable keystroke input
|
|
is not available; requires the Perl module Term::ReadKey.
|
|
|
|
interactive.diffFilter::
|
|
When an interactive command (such as `git add --patch`) shows
|
|
a colorized diff, git will pipe the diff through the shell
|
|
command defined by this configuration variable. The command may
|
|
mark up the diff further for human consumption, provided that it
|
|
retains a one-to-one correspondence with the lines in the
|
|
original diff. Defaults to disabled (no filtering).
|
|
|
|
log.abbrevCommit::
|
|
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
|
|
linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may
|
|
override this option with `--no-abbrev-commit`.
|
|
|
|
log.date::
|
|
Set the default date-time mode for the 'log' command.
|
|
Setting a value for log.date is similar to using 'git log''s
|
|
`--date` option. See linkgit:git-log[1] for details.
|
|
|
|
log.decorate::
|
|
Print out the ref names of any commits that are shown by the log
|
|
command. If 'short' is specified, the ref name prefixes 'refs/heads/',
|
|
'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
|
|
specified, the full ref name (including prefix) will be printed.
|
|
If 'auto' is specified, then if the output is going to a terminal,
|
|
the ref names are shown as if 'short' were given, otherwise no ref
|
|
names are shown. This is the same as the `--decorate` option
|
|
of the `git log`.
|
|
|
|
log.follow::
|
|
If `true`, `git log` will act as if the `--follow` option was used when
|
|
a single <path> is given. This has the same limitations as `--follow`,
|
|
i.e. it cannot be used to follow multiple files and does not work well
|
|
on non-linear history.
|
|
|
|
log.graphColors::
|
|
A list of colors, separated by commas, that can be used to draw
|
|
history lines in `git log --graph`.
|
|
|
|
log.showRoot::
|
|
If true, the initial commit will be shown as a big creation event.
|
|
This is equivalent to a diff against an empty tree.
|
|
Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
|
|
normally hide the root commit will now show it. True by default.
|
|
|
|
log.showSignature::
|
|
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
|
|
linkgit:git-whatchanged[1] assume `--show-signature`.
|
|
|
|
log.mailmap::
|
|
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
|
|
linkgit:git-whatchanged[1] assume `--use-mailmap`.
|
|
|
|
mailinfo.scissors::
|
|
If true, makes linkgit:git-mailinfo[1] (and therefore
|
|
linkgit:git-am[1]) act by default as if the --scissors option
|
|
was provided on the command-line. When active, this features
|
|
removes everything from the message body before a scissors
|
|
line (i.e. consisting mainly of ">8", "8<" and "-").
|
|
|
|
mailmap.file::
|
|
The location of an augmenting mailmap file. The default
|
|
mailmap, located in the root of the repository, is loaded
|
|
first, then the mailmap file pointed to by this variable.
|
|
The location of the mailmap file may be in a repository
|
|
subdirectory, or somewhere outside of the repository itself.
|
|
See linkgit:git-shortlog[1] and linkgit:git-blame[1].
|
|
|
|
mailmap.blob::
|
|
Like `mailmap.file`, but consider the value as a reference to a
|
|
blob in the repository. If both `mailmap.file` and
|
|
`mailmap.blob` are given, both are parsed, with entries from
|
|
`mailmap.file` taking precedence. In a bare repository, this
|
|
defaults to `HEAD:.mailmap`. In a non-bare repository, it
|
|
defaults to empty.
|
|
|
|
man.viewer::
|
|
Specify the programs that may be used to display help in the
|
|
'man' format. See linkgit:git-help[1].
|
|
|
|
man.<tool>.cmd::
|
|
Specify the command to invoke the specified man viewer. The
|
|
specified command is evaluated in shell with the man page
|
|
passed as argument. (See linkgit:git-help[1].)
|
|
|
|
man.<tool>.path::
|
|
Override the path for the given tool that may be used to
|
|
display help in the 'man' format. See linkgit:git-help[1].
|
|
|
|
include::merge-config.txt[]
|
|
|
|
mergetool.<tool>.path::
|
|
Override the path for the given tool. This is useful in case
|
|
your tool is not in the PATH.
|
|
|
|
mergetool.<tool>.cmd::
|
|
Specify the command to invoke the specified merge tool. The
|
|
specified command is evaluated in shell with the following
|
|
variables available: 'BASE' is the name of a temporary file
|
|
containing the common base of the files to be merged, if available;
|
|
'LOCAL' is the name of a temporary file containing the contents of
|
|
the file on the current branch; 'REMOTE' is the name of a temporary
|
|
file containing the contents of the file from the branch being
|
|
merged; 'MERGED' contains the name of the file to which the merge
|
|
tool should write the results of a successful merge.
|
|
|
|
mergetool.<tool>.trustExitCode::
|
|
For a custom merge command, specify whether the exit code of
|
|
the merge command can be used to determine whether the merge was
|
|
successful. If this is not set to true then the merge target file
|
|
timestamp is checked and the merge assumed to have been successful
|
|
if the file has been updated, otherwise the user is prompted to
|
|
indicate the success of the merge.
|
|
|
|
mergetool.meld.hasOutput::
|
|
Older versions of `meld` do not support the `--output` option.
|
|
Git will attempt to detect whether `meld` supports `--output`
|
|
by inspecting the output of `meld --help`. Configuring
|
|
`mergetool.meld.hasOutput` will make Git skip these checks and
|
|
use the configured value instead. Setting `mergetool.meld.hasOutput`
|
|
to `true` tells Git to unconditionally use the `--output` option,
|
|
and `false` avoids using `--output`.
|
|
|
|
mergetool.keepBackup::
|
|
After performing a merge, the original file with conflict markers
|
|
can be saved as a file with a `.orig` extension. If this variable
|
|
is set to `false` then this file is not preserved. Defaults to
|
|
`true` (i.e. keep the backup files).
|
|
|
|
mergetool.keepTemporaries::
|
|
When invoking a custom merge tool, Git uses a set of temporary
|
|
files to pass to the tool. If the tool returns an error and this
|
|
variable is set to `true`, then these temporary files will be
|
|
preserved, otherwise they will be removed after the tool has
|
|
exited. Defaults to `false`.
|
|
|
|
mergetool.writeToTemp::
|
|
Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
|
|
conflicting files in the worktree by default. Git will attempt
|
|
to use a temporary directory for these files when set `true`.
|
|
Defaults to `false`.
|
|
|
|
mergetool.prompt::
|
|
Prompt before each invocation of the merge resolution program.
|
|
|
|
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:
|
|
+
|
|
--
|
|
|
|
* `always` - protocol is always able to be used.
|
|
|
|
* `never` - protocol is never able to be used.
|
|
|
|
* `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.
|
|
|
|
--
|
|
|
|
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.
|
|
|
|
* `1` - the original wire protocol with the addition of a version string
|
|
in the initial response from the server.
|
|
|
|
* `2` - link:technical/protocol-v2.html[wire protocol version 2].
|
|
|
|
--
|
|
|
|
include::pull-config.txt[]
|
|
|
|
include::push-config.txt[]
|
|
|
|
include::rebase-config.txt[]
|
|
|
|
include::receive-config.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.
|
|
|
|
remote.<name>.url::
|
|
The URL of a remote repository. See linkgit:git-fetch[1] or
|
|
linkgit:git-push[1].
|
|
|
|
remote.<name>.pushurl::
|
|
The push URL of a remote repository. See linkgit:git-push[1].
|
|
|
|
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.
|
|
|
|
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`.
|
|
|
|
remote.<name>.fetch::
|
|
The default set of "refspec" for linkgit:git-fetch[1]. See
|
|
linkgit:git-fetch[1].
|
|
|
|
remote.<name>.push::
|
|
The default set of "refspec" for linkgit:git-push[1]. See
|
|
linkgit:git-push[1].
|
|
|
|
remote.<name>.mirror::
|
|
If true, pushing to this remote will automatically behave
|
|
as if the `--mirror` option was given on the command line.
|
|
|
|
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].
|
|
|
|
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].
|
|
|
|
remote.<name>.receivepack::
|
|
The default program to execute on the remote side when pushing. See
|
|
option --receive-pack of linkgit:git-push[1].
|
|
|
|
remote.<name>.uploadpack::
|
|
The default program to execute on the remote side when fetching. See
|
|
option --upload-pack of linkgit:git-fetch-pack[1].
|
|
|
|
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].
|
|
|
|
remote.<name>.vcs::
|
|
Setting this to a value <vcs> will cause Git to interact with
|
|
the remote with the git-remote-<vcs> helper.
|
|
|
|
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.
|
|
|
|
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].
|
|
|
|
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.
|