2007-01-29 00:16:53 +00:00
|
|
|
git-config(1)
|
|
|
|
=============
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
|
|
|
git-config - Get and set repository or global options
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
|
|
|
[verse]
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] name [value [value_regex]]
|
|
|
|
'git config' [<file-option>] [--type=<type>] --add name value
|
|
|
|
'git config' [<file-option>] [--type=<type>] --replace-all name value [value_regex]
|
|
|
|
'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get name [value_regex]
|
|
|
|
'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get-all name [value_regex]
|
|
|
|
'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] [--name-only] --get-regexp name_regex [value_regex]
|
|
|
|
'git config' [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch name URL
|
2008-06-30 06:09:04 +00:00
|
|
|
'git config' [<file-option>] --unset name [value_regex]
|
|
|
|
'git config' [<file-option>] --unset-all name [value_regex]
|
|
|
|
'git config' [<file-option>] --rename-section old_name new_name
|
|
|
|
'git config' [<file-option>] --remove-section name
|
2016-02-19 09:16:02 +00:00
|
|
|
'git config' [<file-option>] [--show-origin] [-z|--null] [--name-only] -l | --list
|
2008-06-30 06:09:04 +00:00
|
|
|
'git config' [<file-option>] --get-color name [default]
|
|
|
|
'git config' [<file-option>] --get-colorbool name [stdout-is-tty]
|
2009-02-07 21:53:00 +00:00
|
|
|
'git config' [<file-option>] -e | --edit
|
2007-01-29 00:16:53 +00:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
You can query/set/replace/unset options with this command. The name is
|
|
|
|
actually the section and the key separated by a dot, and the value will be
|
|
|
|
escaped.
|
|
|
|
|
2016-06-28 11:40:11 +00:00
|
|
|
Multiple lines can be added to an option by using the `--add` option.
|
2007-01-29 00:16:53 +00:00
|
|
|
If you want to update or unset an option which can occur on multiple
|
|
|
|
lines, a POSIX regexp `value_regex` needs to be given. Only the
|
|
|
|
existing values that match the regexp are updated or unset. If
|
|
|
|
you want to handle the lines that do *not* match the regex, just
|
2007-05-31 00:35:36 +00:00
|
|
|
prepend a single exclamation mark in front (see also <<EXAMPLES>>).
|
2007-01-29 00:16:53 +00:00
|
|
|
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
The `--type=<type>` option instructs 'git config' to ensure that incoming and
|
|
|
|
outgoing values are canonicalize-able under the given <type>. If no
|
|
|
|
`--type=<type>` is given, no canonicalization will be performed. Callers may
|
|
|
|
unset an existing `--type` specifier with `--no-type`.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2012-05-05 10:03:52 +00:00
|
|
|
When reading, the values are read from the system, global and
|
|
|
|
repository local configuration files by default, and options
|
2018-10-21 14:02:28 +00:00
|
|
|
`--system`, `--global`, `--local`, `--worktree` and
|
|
|
|
`--file <filename>` can be used to tell the command to read from only
|
|
|
|
that location (see <<FILES>>).
|
2012-05-05 10:03:52 +00:00
|
|
|
|
|
|
|
When writing, the new value is written to the repository local
|
2016-06-28 11:40:11 +00:00
|
|
|
configuration file by default, and options `--system`, `--global`,
|
2018-10-21 14:02:28 +00:00
|
|
|
`--worktree`, `--file <filename>` can be used to tell the command to
|
|
|
|
write to that location (you can say `--local` but that is the
|
|
|
|
default).
|
2007-07-31 22:01:17 +00:00
|
|
|
|
2012-07-29 20:43:21 +00:00
|
|
|
This command will fail with non-zero status upon error. Some exit
|
|
|
|
codes are:
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2016-04-26 18:10:58 +00:00
|
|
|
- The section or key is invalid (ret=1),
|
2016-02-28 11:54:36 +00:00
|
|
|
- no section or name was provided (ret=2),
|
2016-04-26 18:10:58 +00:00
|
|
|
- the config file is invalid (ret=3),
|
|
|
|
- the config file cannot be written (ret=4),
|
2016-02-28 11:54:36 +00:00
|
|
|
- you try to unset an option which does not exist (ret=5),
|
|
|
|
- you try to unset/set an option for which multiple lines match (ret=5), or
|
|
|
|
- you try to use an invalid regexp (ret=6).
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2011-05-17 15:38:52 +00:00
|
|
|
On success, the command returns the exit code 0.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
-------
|
|
|
|
|
|
|
|
--replace-all::
|
|
|
|
Default behavior is to replace at most one line. This replaces
|
|
|
|
all lines matching the key (and optionally the value_regex).
|
|
|
|
|
|
|
|
--add::
|
|
|
|
Adds a new line to the option without altering any existing
|
2009-05-06 22:57:08 +00:00
|
|
|
values. This is the same as providing '^$' as the value_regex
|
|
|
|
in `--replace-all`.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
|
|
|
--get::
|
|
|
|
Get the value for a given key (optionally filtered by a regex
|
|
|
|
matching the value). Returns error code 1 if the key was not
|
2013-07-03 18:27:39 +00:00
|
|
|
found and the last value if multiple key values were found.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
|
|
|
--get-all::
|
2016-02-28 11:54:37 +00:00
|
|
|
Like get, but returns all values for a multi-valued key.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
|
|
|
--get-regexp::
|
2012-03-01 10:59:45 +00:00
|
|
|
Like --get-all, but interprets the name as a regular expression and
|
|
|
|
writes out the key names. Regular expression matching is currently
|
|
|
|
case-sensitive and done against a canonicalized version of the key
|
|
|
|
in which section and variable names are lowercased, but subsection
|
|
|
|
names are not.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2013-07-31 18:14:59 +00:00
|
|
|
--get-urlmatch name URL::
|
|
|
|
When given a two-part name section.key, the value for
|
|
|
|
section.<url>.key whose <url> part matches the best to the
|
|
|
|
given URL is returned (if no such key exists, the value for
|
|
|
|
section.key is used as a fallback). When given just the
|
|
|
|
section as name, do so for all the keys in the section and
|
2016-02-28 11:54:35 +00:00
|
|
|
list them. Returns error code 1 if no value is found.
|
2013-07-31 18:14:59 +00:00
|
|
|
|
2007-01-29 00:16:53 +00:00
|
|
|
--global::
|
2013-07-26 10:42:02 +00:00
|
|
|
For writing options: write to global `~/.gitconfig` file
|
|
|
|
rather than the repository `.git/config`, write to
|
|
|
|
`$XDG_CONFIG_HOME/git/config` file if this file exists and the
|
|
|
|
`~/.gitconfig` file doesn't.
|
2007-05-31 00:35:37 +00:00
|
|
|
+
|
2013-07-26 10:42:02 +00:00
|
|
|
For reading options: read only from global `~/.gitconfig` and from
|
|
|
|
`$XDG_CONFIG_HOME/git/config` rather than from all available files.
|
2007-05-31 00:35:37 +00:00
|
|
|
+
|
|
|
|
See also <<FILES>>.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2007-04-19 03:03:37 +00:00
|
|
|
--system::
|
2013-07-26 10:42:02 +00:00
|
|
|
For writing options: write to system-wide
|
|
|
|
`$(prefix)/etc/gitconfig` rather than the repository
|
|
|
|
`.git/config`.
|
2007-05-31 00:35:37 +00:00
|
|
|
+
|
2013-07-26 10:42:02 +00:00
|
|
|
For reading options: read only from system-wide `$(prefix)/etc/gitconfig`
|
2007-05-31 00:35:37 +00:00
|
|
|
rather than from all available files.
|
|
|
|
+
|
|
|
|
See also <<FILES>>.
|
2007-04-19 03:03:37 +00:00
|
|
|
|
2013-06-17 13:31:31 +00:00
|
|
|
--local::
|
2013-07-26 10:42:02 +00:00
|
|
|
For writing options: write to the repository `.git/config` file.
|
2013-06-17 13:31:31 +00:00
|
|
|
This is the default behavior.
|
|
|
|
+
|
2013-07-26 10:42:02 +00:00
|
|
|
For reading options: read only from the repository `.git/config` rather than
|
2013-06-17 13:31:31 +00:00
|
|
|
from all available files.
|
|
|
|
+
|
|
|
|
See also <<FILES>>.
|
|
|
|
|
2018-10-21 14:02:28 +00:00
|
|
|
--worktree::
|
|
|
|
Similar to `--local` except that `.git/config.worktree` is
|
|
|
|
read from or written to if `extensions.worktreeConfig` is
|
|
|
|
present. If not it's the same as `--local`.
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-f config-file::
|
|
|
|
--file config-file::
|
2007-07-31 09:58:43 +00:00
|
|
|
Use the given config file instead of the one specified by GIT_CONFIG.
|
|
|
|
|
2013-07-11 22:46:47 +00:00
|
|
|
--blob blob::
|
2016-06-28 11:40:11 +00:00
|
|
|
Similar to `--file` but use the given blob instead of a file. E.g.
|
2013-07-11 22:46:47 +00:00
|
|
|
you can use 'master:.gitmodules' to read values from the file
|
|
|
|
'.gitmodules' in the master branch. See "SPECIFYING REVISIONS"
|
|
|
|
section in linkgit:gitrevisions[7] for a more complete list of
|
|
|
|
ways to spell blob names.
|
|
|
|
|
2007-03-02 20:53:33 +00:00
|
|
|
--remove-section::
|
|
|
|
Remove the given section from the configuration file.
|
|
|
|
|
|
|
|
--rename-section::
|
|
|
|
Rename the given section to a new name.
|
|
|
|
|
2007-01-29 00:16:53 +00:00
|
|
|
--unset::
|
|
|
|
Remove the line matching the key from config file.
|
|
|
|
|
|
|
|
--unset-all::
|
2007-03-14 21:08:41 +00:00
|
|
|
Remove all lines matching the key from config file.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-l::
|
|
|
|
--list::
|
2015-08-10 09:46:06 +00:00
|
|
|
List all variables set in config file, along with their values.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
--type <type>::
|
|
|
|
'git config' will ensure that any input or output is valid under the given
|
|
|
|
type constraint(s), and will canonicalize outgoing values in `<type>`'s
|
|
|
|
canonical form.
|
|
|
|
+
|
|
|
|
Valid `<type>`'s include:
|
|
|
|
+
|
|
|
|
- 'bool': canonicalize values as either "true" or "false".
|
|
|
|
- 'int': canonicalize values as simple decimal numbers. An optional suffix of
|
|
|
|
'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, or
|
|
|
|
1073741824 upon input.
|
|
|
|
- 'bool-or-int': canonicalize according to either 'bool' or 'int', as described
|
|
|
|
above.
|
|
|
|
- 'path': canonicalize by adding a leading `~` to the value of `$HOME` and
|
|
|
|
`~user` to the home directory for the specified user. This specifier has no
|
|
|
|
effect when setting the value (but you can use `git config section.variable
|
|
|
|
~/` from the command line to let your shell do the expansion.)
|
|
|
|
- 'expiry-date': canonicalize by converting from a fixed or relative date-string
|
|
|
|
to a timestamp. This specifier has no effect when setting the value.
|
2018-04-10 00:18:31 +00:00
|
|
|
- 'color': When getting a value, canonicalize by converting to an ANSI color
|
|
|
|
escape sequence. When setting a value, a sanity-check is performed to ensure
|
|
|
|
that the given value is canonicalize-able as an ANSI color, but it is written
|
|
|
|
as-is.
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
+
|
2007-01-29 00:16:53 +00:00
|
|
|
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
--bool::
|
2007-01-29 00:16:53 +00:00
|
|
|
--int::
|
2009-03-07 17:14:06 +00:00
|
|
|
--bool-or-int::
|
2009-12-30 16:51:53 +00:00
|
|
|
--path::
|
2017-11-18 02:27:27 +00:00
|
|
|
--expiry-date::
|
2018-09-19 16:38:19 +00:00
|
|
|
Historical options for selecting a type specifier. Prefer instead `--type`
|
|
|
|
(see above).
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
|
|
|
|
--no-type::
|
|
|
|
Un-sets the previously set type specifier (if one was previously set). This
|
|
|
|
option requests that 'git config' not canonicalize the retrieved variable.
|
|
|
|
`--no-type` has no effect without `--type=<type>` or `--<type>`.
|
2017-11-18 02:27:27 +00:00
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-z::
|
|
|
|
--null::
|
2007-06-25 14:03:55 +00:00
|
|
|
For all options that output values and/or keys, always
|
2008-01-29 19:38:55 +00:00
|
|
|
end values with the null character (instead of a
|
2007-06-25 14:03:55 +00:00
|
|
|
newline). Use newline instead as a delimiter between
|
|
|
|
key and value. This allows for secure parsing of the
|
|
|
|
output without getting confused e.g. by values that
|
|
|
|
contain line breaks.
|
|
|
|
|
2015-08-10 09:46:06 +00:00
|
|
|
--name-only::
|
|
|
|
Output only the names of config variables for `--list` or
|
|
|
|
`--get-regexp`.
|
|
|
|
|
2016-02-19 09:16:02 +00:00
|
|
|
--show-origin::
|
|
|
|
Augment the output of all queried config options with the
|
|
|
|
origin type (file, standard input, blob, command line) and
|
|
|
|
the actual origin (config file path, ref, or blob id if
|
|
|
|
applicable).
|
|
|
|
|
2007-12-06 01:26:11 +00:00
|
|
|
--get-colorbool name [stdout-is-tty]::
|
|
|
|
|
|
|
|
Find the color setting for `name` (e.g. `color.diff`) and output
|
|
|
|
"true" or "false". `stdout-is-tty` should be either "true" or
|
|
|
|
"false", and is taken into account when configuration says
|
|
|
|
"auto". If `stdout-is-tty` is missing, then checks the standard
|
|
|
|
output of the command itself, and exits with status 0 if color
|
|
|
|
is to be used, or exits with status 1 otherwise.
|
2008-04-09 19:32:06 +00:00
|
|
|
When the color setting for `name` is undefined, the command uses
|
|
|
|
`color.ui` as fallback.
|
2007-12-06 01:26:11 +00:00
|
|
|
|
2009-05-06 22:57:08 +00:00
|
|
|
--get-color name [default]::
|
2007-11-28 06:41:05 +00:00
|
|
|
|
|
|
|
Find the color configured for `name` (e.g. `color.diff.new`) and
|
|
|
|
output it as the ANSI color escape sequence to the standard
|
|
|
|
output. The optional `default` parameter is used instead, if
|
|
|
|
there is no color configured for `name`.
|
2018-04-10 00:18:31 +00:00
|
|
|
+
|
2019-03-05 04:20:51 +00:00
|
|
|
`--type=color [--default=<default>]` is preferred over `--get-color`
|
|
|
|
(but note that `--get-color` will omit the trailing newline printed by
|
|
|
|
`--type=color`).
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2009-02-07 21:53:00 +00:00
|
|
|
-e::
|
|
|
|
--edit::
|
|
|
|
Opens an editor to modify the specified config file; either
|
2016-06-28 11:40:11 +00:00
|
|
|
`--system`, `--global`, or repository (default).
|
2009-02-07 21:53:00 +00:00
|
|
|
|
2013-05-09 01:16:55 +00:00
|
|
|
--[no-]includes::
|
config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-06 09:54:04 +00:00
|
|
|
Respect `include.*` directives in config files when looking up
|
2015-01-19 19:58:47 +00:00
|
|
|
values. Defaults to `off` when a specific file is given (e.g.,
|
|
|
|
using `--file`, `--global`, etc) and `on` when searching all
|
|
|
|
config files.
|
config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-06 09:54:04 +00:00
|
|
|
|
builtin/config: introduce `--default`
For some use cases, callers of the `git-config(1)` builtin would like to
fallback to default values when the variable asked for does not exist.
In addition, users would like to use existing type specifiers to ensure
that values are parsed correctly when they do exist in the
configuration.
For example, to fetch a value without a type specifier and fallback to
`$fallback`, the following is required:
$ git config core.foo || echo "$fallback"
This is fine for most values, but can be tricky for difficult-to-express
`$fallback`'s, like ANSI color codes.
This motivates `--get-color`, which is a one-off exception to the normal
type specifier rules wherein a user specifies both the configuration
variable and an optional fallback. Both are formatted according to their
type specifier, which eases the burden on the user to ensure that values
are correctly formatted.
This commit (and those following it in this series) aim to eventually
replace `--get-color` with a consistent alternative. By introducing
`--default`, we allow the `--get-color` action to be promoted to a
`--type=color` type specifier, retaining the "fallback" behavior via the
`--default` flag introduced in this commit.
For example, we aim to replace:
$ git config --get-color variable [default] [...]
with:
$ git config --default default --type=color variable [...]
Values filled by `--default` behave exactly as if they were present in
the affected configuration file; they will be parsed by type specifiers
without the knowledge that they are not themselves present in the
configuration.
Specifically, this means that the following will work:
$ git config --int --default 1M does.not.exist
1048576
In subsequent commits, we will offer `--type=color`, which (in
conjunction with `--default`) will be sufficient to replace
`--get-color`.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 00:18:26 +00:00
|
|
|
--default <value>::
|
|
|
|
When using `--get`, and the requested variable is not found, behave as if
|
|
|
|
<value> were the value assigned to the that variable.
|
|
|
|
|
2018-02-21 18:51:43 +00:00
|
|
|
CONFIGURATION
|
|
|
|
-------------
|
|
|
|
`pager.config` is only respected when listing configuration, i.e., when
|
|
|
|
using `--list` or any of the `--get-*` which may return multiple results.
|
2018-02-21 18:51:44 +00:00
|
|
|
The default is to use a pager.
|
2018-02-21 18:51:43 +00:00
|
|
|
|
2007-05-31 00:35:37 +00:00
|
|
|
[[FILES]]
|
|
|
|
FILES
|
|
|
|
-----
|
|
|
|
|
2016-06-28 11:40:11 +00:00
|
|
|
If not set explicitly with `--file`, there are four files where
|
2010-01-09 23:33:00 +00:00
|
|
|
'git config' will search for configuration options:
|
2007-05-31 00:35:37 +00:00
|
|
|
|
2013-07-07 19:49:56 +00:00
|
|
|
$(prefix)/etc/gitconfig::
|
|
|
|
System-wide configuration file.
|
2007-05-31 00:35:37 +00:00
|
|
|
|
2012-06-22 09:03:23 +00:00
|
|
|
$XDG_CONFIG_HOME/git/config::
|
|
|
|
Second user-specific configuration file. If $XDG_CONFIG_HOME is not set
|
2013-07-26 10:42:02 +00:00
|
|
|
or empty, `$HOME/.config/git/config` will be used. Any single-valued
|
2012-06-22 09:03:23 +00:00
|
|
|
variable set in this file will be overwritten by whatever is in
|
2013-07-26 10:42:02 +00:00
|
|
|
`~/.gitconfig`. It is a good idea not to create this file if
|
2012-06-22 09:03:23 +00:00
|
|
|
you sometimes use older versions of Git, as support for this
|
|
|
|
file was added fairly recently.
|
|
|
|
|
2013-07-07 19:49:56 +00:00
|
|
|
~/.gitconfig::
|
|
|
|
User-specific configuration file. Also called "global"
|
|
|
|
configuration file.
|
|
|
|
|
|
|
|
$GIT_DIR/config::
|
|
|
|
Repository specific configuration file.
|
2007-05-31 00:35:37 +00:00
|
|
|
|
2018-10-21 14:02:28 +00:00
|
|
|
$GIT_DIR/config.worktree::
|
|
|
|
This is optional and is only searched when
|
|
|
|
`extensions.worktreeConfig` is present in $GIT_DIR/config.
|
|
|
|
|
2007-05-31 00:35:37 +00:00
|
|
|
If no further options are given, all reading options will read all of these
|
|
|
|
files that are available. If the global or the system-wide configuration
|
|
|
|
file are not available they will be ignored. If the repository configuration
|
2010-01-09 23:33:00 +00:00
|
|
|
file is not available or readable, 'git config' will exit with a non-zero
|
2007-05-31 00:35:37 +00:00
|
|
|
error code. However, in neither case will an error message be issued.
|
|
|
|
|
2013-07-07 19:49:56 +00:00
|
|
|
The files are read in the order given above, with last value found taking
|
|
|
|
precedence over values read earlier. When multiple values are taken then all
|
|
|
|
values of a key from all files will be used.
|
|
|
|
|
2016-08-23 17:33:21 +00:00
|
|
|
You may override individual configuration parameters when running any git
|
|
|
|
command by using the `-c` option. See linkgit:git[1] for details.
|
|
|
|
|
2007-05-31 00:35:37 +00:00
|
|
|
All writing options will per default write to the repository specific
|
2016-06-28 11:40:11 +00:00
|
|
|
configuration file. Note that this also affects options like `--replace-all`
|
|
|
|
and `--unset`. *'git config' will only ever change one file at a time*.
|
2007-05-31 00:35:37 +00:00
|
|
|
|
2014-05-21 18:52:26 +00:00
|
|
|
You can override these rules either by command-line options or by environment
|
2018-10-21 14:02:28 +00:00
|
|
|
variables. The `--global`, `--system` and `--worktree` options will limit
|
|
|
|
the file used to the global, system-wide or per-worktree file respectively.
|
|
|
|
The `GIT_CONFIG` environment variable has a similar effect, but you
|
|
|
|
can specify any filename you want.
|
2007-05-31 00:35:37 +00:00
|
|
|
|
|
|
|
|
2007-01-29 00:16:53 +00:00
|
|
|
ENVIRONMENT
|
|
|
|
-----------
|
|
|
|
|
|
|
|
GIT_CONFIG::
|
|
|
|
Take the configuration from the given file instead of .git/config.
|
2007-05-31 00:35:37 +00:00
|
|
|
Using the "--global" option forces this to ~/.gitconfig. Using the
|
|
|
|
"--system" option forces this to $(prefix)/etc/gitconfig.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2012-10-14 08:53:59 +00:00
|
|
|
GIT_CONFIG_NOSYSTEM::
|
|
|
|
Whether to skip reading settings from the system-wide
|
|
|
|
$(prefix)/etc/gitconfig file. See linkgit:git[1] for details.
|
|
|
|
|
2007-05-31 00:35:37 +00:00
|
|
|
See also <<FILES>>.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2007-05-31 00:35:36 +00:00
|
|
|
|
|
|
|
[[EXAMPLES]]
|
|
|
|
EXAMPLES
|
|
|
|
--------
|
2007-01-29 00:16:53 +00:00
|
|
|
|
|
|
|
Given a .git/config like this:
|
|
|
|
|
|
|
|
#
|
|
|
|
# This is the config file, and
|
|
|
|
# a '#' or ';' character indicates
|
|
|
|
# a comment
|
|
|
|
#
|
|
|
|
|
|
|
|
; core variables
|
|
|
|
[core]
|
|
|
|
; Don't trust file modes
|
|
|
|
filemode = false
|
|
|
|
|
|
|
|
; Our diff algorithm
|
|
|
|
[diff]
|
2008-07-27 11:12:15 +00:00
|
|
|
external = /usr/local/bin/diff-wrapper
|
2007-01-29 00:16:53 +00:00
|
|
|
renames = true
|
|
|
|
|
|
|
|
; Proxy settings
|
|
|
|
[core]
|
2012-08-18 23:35:09 +00:00
|
|
|
gitproxy=proxy-command for kernel.org
|
2007-01-29 00:16:53 +00:00
|
|
|
gitproxy=default-proxy ; for all the rest
|
|
|
|
|
2013-07-31 18:14:59 +00:00
|
|
|
; HTTP
|
|
|
|
[http]
|
|
|
|
sslVerify
|
|
|
|
[http "https://weak.example.com"]
|
|
|
|
sslVerify = false
|
|
|
|
cookieFile = /tmp/cookie.txt
|
|
|
|
|
2007-01-29 00:16:53 +00:00
|
|
|
you can set the filemode to true with
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config core.filemode true
|
|
|
|
------------
|
|
|
|
|
|
|
|
The hypothetical proxy command entries actually have a postfix to discern
|
|
|
|
what URL they apply to. Here is how to change the entry for kernel.org
|
|
|
|
to "ssh".
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
|
|
|
|
------------
|
|
|
|
|
|
|
|
This makes sure that only the key/value pair for kernel.org is replaced.
|
|
|
|
|
|
|
|
To delete the entry for renames, do
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config --unset diff.renames
|
|
|
|
------------
|
|
|
|
|
|
|
|
If you want to delete an entry for a multivar (like core.gitproxy above),
|
|
|
|
you have to provide a regex matching the value of exactly one line.
|
|
|
|
|
|
|
|
To query the value for a given key, do
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config --get core.filemode
|
|
|
|
------------
|
|
|
|
|
|
|
|
or
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config core.filemode
|
|
|
|
------------
|
|
|
|
|
|
|
|
or, to query a multivar:
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config --get core.gitproxy "for kernel.org$"
|
|
|
|
------------
|
|
|
|
|
|
|
|
If you want to know all the values for a multivar, do:
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config --get-all core.gitproxy
|
|
|
|
------------
|
|
|
|
|
2008-12-12 09:00:41 +00:00
|
|
|
If you like to live dangerously, you can replace *all* core.gitproxy by a
|
2007-01-29 00:16:53 +00:00
|
|
|
new one with
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config --replace-all core.gitproxy ssh
|
|
|
|
------------
|
|
|
|
|
|
|
|
However, if you really only want to replace the line for the default proxy,
|
|
|
|
i.e. the one without a "for ..." postfix, do something like this:
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config core.gitproxy ssh '! for '
|
|
|
|
------------
|
|
|
|
|
|
|
|
To actually match only values with an exclamation mark, you have to
|
|
|
|
|
|
|
|
------------
|
|
|
|
% git config section.key value '[!]'
|
|
|
|
------------
|
|
|
|
|
|
|
|
To add a new proxy, without altering any of the existing ones, use
|
|
|
|
|
|
|
|
------------
|
2012-08-18 17:32:10 +00:00
|
|
|
% git config --add core.gitproxy '"proxy-command" for example.com'
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
2007-11-28 06:41:05 +00:00
|
|
|
An example to use customized color from the configuration in your
|
|
|
|
script:
|
|
|
|
|
|
|
|
------------
|
|
|
|
#!/bin/sh
|
|
|
|
WS=$(git config --get-color color.diff.whitespace "blue reverse")
|
|
|
|
RESET=$(git config --get-color "" "reset")
|
|
|
|
echo "${WS}your whitespace color or blue reverse${RESET}"
|
|
|
|
------------
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2013-07-31 18:14:59 +00:00
|
|
|
For URLs in `https://weak.example.com`, `http.sslVerify` is set to
|
|
|
|
false, while it is set to `true` for all others:
|
|
|
|
|
|
|
|
------------
|
2018-09-19 16:38:18 +00:00
|
|
|
% git config --type=bool --get-urlmatch http.sslverify https://good.example.com
|
2013-07-31 18:14:59 +00:00
|
|
|
true
|
2018-09-19 16:38:18 +00:00
|
|
|
% git config --type=bool --get-urlmatch http.sslverify https://weak.example.com
|
2013-07-31 18:14:59 +00:00
|
|
|
false
|
|
|
|
% git config --get-urlmatch http https://weak.example.com
|
2015-03-11 20:32:45 +00:00
|
|
|
http.cookieFile /tmp/cookie.txt
|
2013-07-31 18:14:59 +00:00
|
|
|
http.sslverify false
|
|
|
|
------------
|
|
|
|
|
2007-01-29 00:16:53 +00:00
|
|
|
include::config.txt[]
|
|
|
|
|
2018-08-08 19:50:20 +00:00
|
|
|
BUGS
|
|
|
|
----
|
|
|
|
When using the deprecated `[section.subsection]` syntax, changing a value
|
|
|
|
will result in adding a multi-line key instead of a change, if the subsection
|
|
|
|
is given with at least one uppercase character. For example when the config
|
|
|
|
looks like
|
|
|
|
|
|
|
|
--------
|
|
|
|
[section.subsection]
|
|
|
|
key = value1
|
|
|
|
--------
|
|
|
|
|
|
|
|
and running `git config section.Subsection.key value2` will result in
|
|
|
|
|
|
|
|
--------
|
|
|
|
[section.subsection]
|
|
|
|
key = value1
|
|
|
|
key = value2
|
|
|
|
--------
|
|
|
|
|
|
|
|
|
2007-01-29 00:16:53 +00:00
|
|
|
GIT
|
|
|
|
---
|
2008-06-06 07:07:32 +00:00
|
|
|
Part of the linkgit:git[1] suite
|