f7ade6c980
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
1222 lines
48 KiB
Plaintext
1222 lines
48 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::config/format.txt[]
|
|
|
|
include::config/filter.txt[]
|
|
|
|
include::config/fsck.txt[]
|
|
|
|
include::config/gc.txt[]
|
|
|
|
include::config/gitcvs.txt[]
|
|
|
|
include::config/gitweb.txt[]
|
|
|
|
include::config/grep.txt[]
|
|
|
|
include::config/gpg.txt[]
|
|
|
|
include::config/gui.txt[]
|
|
|
|
include::config/guitool.txt[]
|
|
|
|
include::config/help.txt[]
|
|
|
|
include::config/http.txt[]
|
|
|
|
include::config/i18n.txt[]
|
|
|
|
include::config/imap.txt[]
|
|
|
|
include::config/index.txt[]
|
|
|
|
include::config/init.txt[]
|
|
|
|
include::config/instaweb.txt[]
|
|
|
|
include::config/interactive.txt[]
|
|
|
|
include::config/log.txt[]
|
|
|
|
include::config/mailinfo.txt[]
|
|
|
|
include::config/mailmap.txt[]
|
|
|
|
include::config/man.txt[]
|
|
|
|
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].
|
|
|
|
include::config/ssh.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.
|