global/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2026-01-10 01:56:42 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
ecc7c8841de40a38637680509f7e1e6ce25d89ca
git/Documentation/config.txt
Elijah Newren ecc7c8841d repo_read_index: add config to expect files outside sparse patterns 
Typically with sparse checkouts, we expect files outside the sparsity
patterns to be marked as SKIP_WORKTREE and be missing from the working
tree.  Sometimes this expectation would be violated however; including
in cases such as:
  * users grabbing files from elsewhere and writing them to the worktree
    (perhaps by editing a cached copy in an editor, copying/renaming, or
     even untarring)
  * various git commands having incomplete or no support for the
    SKIP_WORKTREE bit[1,2]
  * users attempting to "abort" a sparse-checkout operation with a
    not-so-early Ctrl+C (updating $GIT_DIR/info/sparse-checkout and the
    working tree is not atomic)[3].
When the SKIP_WORKTREE bit in the index did not reflect the presence of
the file in the working tree, it traditionally caused confusion and was
difficult to detect and recover from.  So, in a sparse checkout, since
af6a51875a (repo_read_index: clear SKIP_WORKTREE bit from files present
in worktree, 2022-01-14), Git automatically clears the SKIP_WORKTREE
bit at index read time for entries corresponding to files that are
present in the working tree.

There is another workflow, however, where it is expected that paths
outside the sparsity patterns appear to exist in the working tree and
that they do not lose the SKIP_WORKTREE bit, at least until they get
modified.  A Git-aware virtual file system[4] takes advantage of its
position as a file system driver to expose all files in the working
tree, fetch them on demand using partial clone on access, and tell Git
to pay attention to them on demand by updating the sparse checkout
pattern on writes.  This means that commands like "git status" only have
to examine files that have potentially been modified, whereas commands
like "ls" are able to show the entire codebase without requiring manual
updates to the sparse checkout pattern.

Thus since af6a51875a, Git with such Git-aware virtual file systems
unsets the SKIP_WORKTREE bit for all files and commands like "git
status" have to fetch and examine them all.

Introduce a configuration setting sparse.expectFilesOutsideOfPatterns to
allow limiting the tracked set of files to a small set once again.  A
Git-aware virtual file system or other application that wants to
maintain files outside of the sparse checkout can set this in a
repository to instruct Git not to check for the presence of
SKIP_WORKTREE files.  The setting defaults to false, so most users of
sparse checkout will still get the benefit of an automatically updating
index to recover from the variety of difficult issues detailed in
af6a51875a for paths with SKIP_WORKTREE set despite the path being
present.

[1] https://lore.kernel.org/git/xmqqbmb1a7ga.fsf@gitster-ct.c.googlers.com/
[2] The three long paragraphs in the middle of
    https://lore.kernel.org/git/CABPp-BH9tju7WVm=QZDOvaMDdZbpNXrVWQdN-jmfN8wC6YVhmw@mail.gmail.com/
[3] https://lore.kernel.org/git/CABPp-BFnFpzwGC11TLoLs8YK5yiisA5D5-fFjXnJsbESVDwZsA@mail.gmail.com/
[4] such as the vfsd described in
https://lore.kernel.org/git/20220207190320.2960362-1-jonathantanmy@google.com/

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-01 23:37:48 -08:00

504 lines
16 KiB
Plaintext
Raw Blame History

CONFIGURATION FILE
------------------
The Git configuration file contains a number of variables that affect
the Git commands' behavior. The files `.git/config` and optionally
`config.worktree` (see the "CONFIGURATION FILE" section of
linkgit:git-worktree[1]) in each repository are used to store the
configuration for that repository, and `$HOME/.gitconfig` is used to
store a per-user configuration as fallback values for the `.git/config`
file. The file `/etc/gitconfig` can be used to store a system-wide
default configuration.
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 backslash 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 systems)
`onbranch`::
The data that follows the keyword `onbranch:` is taken to be a
pattern with standard globbing wildcards and two additional
ones, `**/` and `/**`, that can match multiple path components.
If we are in a worktree where the name of the branch that is
currently checked out matches the pattern, the include condition
is met.
+
If the pattern ends with `/`, `**` will be automatically added. For
example, the pattern `foo/` becomes `foo/**`. In other words, it matches
all branches that begin with `foo/`. This is useful if your branches are
organized hierarchically and you would like to apply a configuration to
all the branches in that hierarchy.
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
; include only if we are in a worktree where foo-branch is
; currently checked out
[includeIf "onbranch:foo-branch"]
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`, `white` and `default`. The first
color given is the foreground; the second is the background. All the
basic colors except `normal` and `default` have a bright variant that can
be specified by prefixing the color with `bright`, like `brightred`.
+
The color `normal` makes no change to the color. It is the same as an
empty string, but can be used as the foreground color when specifying a
background color alone (for example, "normal red").
+
The color `default` explicitly resets the color to the terminal default,
for example to specify a cleared background. Although it varies between
terminals, this is usually not the same as setting to "white black".
+
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).
+
The pseudo-attribute `reset` resets all colors and attributes before
applying the specified coloring. For example, `reset green` will result
in a green foreground and default background without any active
attributes.
+
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.
+
If a path starts with `%(prefix)/`, the remainder is interpreted as a
path relative to Git's "runtime prefix", i.e. relative to the location
where Git itself was installed. For example, `%(prefix)/bin/` refers to
the directory in which the Git executable itself lives. If Git was
compiled without runtime prefix support, the compiled-in prefix will be
substituted instead. In the unlikely event that a literal path needs to
be specified that should _not_ be expanded, it needs to be prefixed by
`./`, like so: `./%(prefix)/bin`.
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/clone.txt[]
include::config/color.txt[]
include::config/column.txt[]
include::config/commit.txt[]
include::config/commitgraph.txt[]
include::config/credential.txt[]
include::config/completion.txt[]
include::config/diff.txt[]
include::config/difftool.txt[]
include::config/extensions.txt[]
include::config/fastimport.txt[]
include::config/feature.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/lsrefs.txt[]
include::config/mailinfo.txt[]
include::config/mailmap.txt[]
include::config/maintenance.txt[]
include::config/man.txt[]
include::config/merge.txt[]
include::config/mergetool.txt[]
include::config/notes.txt[]
include::config/pack.txt[]
include::config/pager.txt[]
include::config/pretty.txt[]
include::config/protocol.txt[]
include::config/pull.txt[]
include::config/push.txt[]
include::config/rebase.txt[]
include::config/receive.txt[]
include::config/remote.txt[]
include::config/remotes.txt[]
include::config/repack.txt[]
include::config/rerere.txt[]
include::config/reset.txt[]
include::config/sendemail.txt[]
include::config/sequencer.txt[]
include::config/showbranch.txt[]
include::config/sparse.txt[]
include::config/splitindex.txt[]
include::config/ssh.txt[]
include::config/status.txt[]
include::config/stash.txt[]
include::config/submodule.txt[]
include::config/tag.txt[]
include::config/tar.txt[]
include::config/trace2.txt[]
include::config/transfer.txt[]
include::config/uploadarchive.txt[]
include::config/uploadpack.txt[]
include::config/url.txt[]
include::config/user.txt[]
include::config/versionsort.txt[]
include::config/web.txt[]
include::config/worktree.txt[]
Reference in New Issue View Git Blame Copy Permalink