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: introduce "list" subcommand
While git-config(1) has several modes, those modes are not exposed with
subcommands but instead by specifying action flags like `--unset` or
`--list`. This user interface is not really in line with how our more
modern commands work, where it is a lot more customary to say e.g. `git
remote list`. Furthermore, to add to the confusion, git-config(1) also
allows the user to request modes implicitly by just specifying the
correct number of arguments. Thus, `git config foo.bar` will retrieve
the value of "foo.bar" while `git config foo.bar baz` will set it to
"baz".
Overall, this makes for a confusing interface that could really use a
makeover. It hurts discoverability of what you can do with git-config(1)
and is comparatively easy to get wrong. Converting the command to have
subcommands instead would go a long way to help address these issues.
One concern in this context is backwards compatibility. Luckily, we can
introduce subcommands without breaking backwards compatibility at all.
This is because all the implicit modes of git-config(1) require that the
first argument is a properly formatted config key. And as config keys
_must_ have a dot in their name, any value without a dot would have been
discarded by git-config(1) previous to this change. Thus, given that
none of the subcommands do have a dot, they are unambiguous.
Introduce the first such new subcommand, which is "git config list". To
retain backwards compatibility we only conditionally use subcommands and
will fall back to the old syntax in case no subcommand was detected.
This should help to transition to the new-style syntax until we
eventually deprecate and remove the old-style syntax.
Note that the way we handle this we're duplicating some functionality
across old and new syntax. While this isn't pretty, it helps us to
ensure that there really is no change in behaviour for the old syntax.
Amend tests such that we run them both with old and new style syntax.
As tests are now run twice, state from the first run may be still be
around in the second run and thus cause tests to fail. Add cleanup logic
as required to fix such tests.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-05-06 08:56:24 +00:00
|
|
|
'git config list' [<file-option>] [<display-option>] [--includes]
|
2024-05-06 08:56:29 +00:00
|
|
|
'git config get' [<file-option>] [<display-option>] [--includes] [--all] [--regexp=<regexp>] [--value=<value>] [--fixed-value] [--default=<default>] <name>
|
2024-05-06 08:56:38 +00:00
|
|
|
'git config set' [<file-option>] [--type=<type>] [--all] [--value=<value>] [--fixed-value] <name> <value>
|
|
|
|
|
'git config unset' [<file-option>] [--all] [--value=<value>] [--fixed-value] <name> <value>
|
2024-05-06 08:56:43 +00:00
|
|
|
'git config rename-section' [<file-option>] <old-name> <new-name>
|
2024-05-06 08:56:47 +00:00
|
|
|
'git config remove-section' [<file-option>] <name>
|
2024-05-06 08:56:52 +00:00
|
|
|
'git config edit' [<file-option>]
|
2021-11-06 18:48:51 +00:00
|
|
|
'git config' [<file-option>] --get-colorbool <name> [<stdout-is-tty>]
|
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.
|
|
|
|
|
|
2024-05-06 08:56:33 +00:00
|
|
|
Multiple lines can be added to an option by using the `--append` option.
|
2007-01-29 00:16:53 +00:00
|
|
|
If you want to update or unset an option which can occur on multiple
|
2020-11-25 23:01:31 +00:00
|
|
|
lines, a `value-pattern` (which is an extended regular expression,
|
|
|
|
|
unless the `--fixed-value` option is given) needs to be given. Only the
|
|
|
|
|
existing values that match the pattern are updated or unset. If
|
|
|
|
|
you want to handle the lines that do *not* match the pattern, just
|
|
|
|
|
prepend a single exclamation mark in front (see also <<EXAMPLES>>),
|
|
|
|
|
but note that this only works when the `--fixed-value` option is not
|
|
|
|
|
in use.
|
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
|
|
|
|
2021-09-13 21:23:05 +00:00
|
|
|
A list of all available configuration variables can be obtained using the
|
|
|
|
|
`git help --config` command.
|
|
|
|
|
|
builtin/config: introduce "list" subcommand
While git-config(1) has several modes, those modes are not exposed with
subcommands but instead by specifying action flags like `--unset` or
`--list`. This user interface is not really in line with how our more
modern commands work, where it is a lot more customary to say e.g. `git
remote list`. Furthermore, to add to the confusion, git-config(1) also
allows the user to request modes implicitly by just specifying the
correct number of arguments. Thus, `git config foo.bar` will retrieve
the value of "foo.bar" while `git config foo.bar baz` will set it to
"baz".
Overall, this makes for a confusing interface that could really use a
makeover. It hurts discoverability of what you can do with git-config(1)
and is comparatively easy to get wrong. Converting the command to have
subcommands instead would go a long way to help address these issues.
One concern in this context is backwards compatibility. Luckily, we can
introduce subcommands without breaking backwards compatibility at all.
This is because all the implicit modes of git-config(1) require that the
first argument is a properly formatted config key. And as config keys
_must_ have a dot in their name, any value without a dot would have been
discarded by git-config(1) previous to this change. Thus, given that
none of the subcommands do have a dot, they are unambiguous.
Introduce the first such new subcommand, which is "git config list". To
retain backwards compatibility we only conditionally use subcommands and
will fall back to the old syntax in case no subcommand was detected.
This should help to transition to the new-style syntax until we
eventually deprecate and remove the old-style syntax.
Note that the way we handle this we're duplicating some functionality
across old and new syntax. While this isn't pretty, it helps us to
ensure that there really is no change in behaviour for the old syntax.
Amend tests such that we run them both with old and new style syntax.
As tests are now run twice, state from the first run may be still be
around in the second run and thus cause tests to fail. Add cleanup logic
as required to fix such tests.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-05-06 08:56:24 +00:00
|
|
|
COMMANDS
|
|
|
|
|
--------
|
|
|
|
|
|
|
|
|
|
list::
|
|
|
|
|
List all variables set in config file, along with their values.
|
|
|
|
|
|
2024-05-06 08:56:29 +00:00
|
|
|
get::
|
|
|
|
|
Emits the value of the specified key. If key is present multiple times
|
|
|
|
|
in the configuration, emits the last value. If `--all` is specified,
|
|
|
|
|
emits all values associated with key. Returns error code 1 if key is
|
|
|
|
|
not present.
|
|
|
|
|
|
2024-05-06 08:56:33 +00:00
|
|
|
set::
|
|
|
|
|
Set value for one or more config options. By default, this command
|
|
|
|
|
refuses to write multi-valued config options. Passing `--all` will
|
|
|
|
|
replace all multi-valued config options with the new value, whereas
|
|
|
|
|
`--value=` will replace all config options whose values match the given
|
|
|
|
|
pattern.
|
|
|
|
|
|
2024-05-06 08:56:38 +00:00
|
|
|
unset::
|
|
|
|
|
Unset value for one or more config options. By default, this command
|
|
|
|
|
refuses to unset multi-valued keys. Passing `--all` will unset all
|
|
|
|
|
multi-valued config options, whereas `--value` will unset all config
|
|
|
|
|
options whose values match the given pattern.
|
|
|
|
|
|
2024-05-06 08:56:43 +00:00
|
|
|
rename-section::
|
|
|
|
|
Rename the given section to a new name.
|
|
|
|
|
|
2024-05-06 08:56:47 +00:00
|
|
|
remove-section::
|
|
|
|
|
Remove the given section from the configuration file.
|
|
|
|
|
|
2024-05-06 08:56:52 +00:00
|
|
|
edit::
|
|
|
|
|
Opens an editor to modify the specified config file; either
|
|
|
|
|
`--system`, `--global`, `--local` (default), `--worktree`, or
|
|
|
|
|
`--file <config-file>`.
|
|
|
|
|
|
2021-07-14 21:38:27 +00:00
|
|
|
[[OPTIONS]]
|
2007-01-29 00:16:53 +00:00
|
|
|
OPTIONS
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
--replace-all::
|
|
|
|
|
Default behavior is to replace at most one line. This replaces
|
2020-11-25 22:12:50 +00:00
|
|
|
all lines matching the key (and optionally the `value-pattern`).
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2024-05-06 08:56:33 +00:00
|
|
|
--append::
|
2007-01-29 00:16:53 +00:00
|
|
|
Adds a new line to the option without altering any existing
|
2024-05-06 08:56:33 +00:00
|
|
|
values. This is the same as providing '--value=^$' in `set`.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
config: fix --comment formatting
When git adds comments itself (like "rebase -i" todo list and
"commit -e" log message editor), it always gives a comment
introducer "#" followed by a Space before the message, except for
the recently introduced "git config --comment", where the users are
forced to say " this is my comment" if they want to add their
comment in this usual format; otherwise their comment string will
end up without a space after the "#".
Make it more ergonomic, while keeping it possible to also use this
unusual style, by massaging the comment string at the UI layer with
a set of simple rules:
* If the given comment string begins with '#', it is passed intact.
* Otherwise, "# " is prefixed.
* A string with LF in it cannot be used as a comment string.
Right now there is only one "front-end" that accepts end-user
comment string and calls the underlying machinery to add or modify
configuration file with comments, but to make sure that the future
callers perform similar massaging as they see fit, add a sanity
check logic in git_config_set_multivar_in_file_gently(), which is
the single choke point in the codepaths that consumes the comment
string.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-15 19:43:58 +00:00
|
|
|
--comment <message>::
|
|
|
|
|
Append a comment at the end of new or modified lines.
|
config: allow tweaking whitespace between value and comment
Extending the previous step, this allows the whitespace placed after
the value before the "# comment message" to be tweaked by tweaking
the preprocessing rule to:
* If the given comment string begins with one or more whitespace
characters followed by '#', it is passed intact.
* If the given comment string begins with '#', a Space is
prepended.
* Otherwise, " # " (Space, '#', Space) is prefixed.
* A string with LF in it cannot be used as a comment string.
Unlike the previous step, which unconditionally added a space after
the value before writing the "# comment string", because the above
preprocessing already gives a whitespace before the '#', the
resulting string is written immediately after copying the value.
And the sanity checking rule becomes
* comment string after the above massaging that comes into
git_config_set_multivar_in_file_gently() must
- begin with zero or more whitespace characters followed by '#'.
- not have a LF in it.
I personally think this is over-engineered, but since I thought
things through anyway, here it is in the patch form. The logic to
tweak end-user supplied comment string is encapsulated in a new
helper function, git_config_prepare_comment_string(), so if new
front-end callers would want to use the same massaging rules, it is
easily reused.
Unfortunately I do not think of a way to tweak the preprocessing
rules further to optionally allow having no blank after the value,
i.e. to produce
[section]
variable = value#comment
(which is a valid way to say section.variable=value, by the way)
without sacrificing the ergonomics for the more usual case, so this
time I really stop here.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-15 22:26:40 +00:00
|
|
|
|
|
|
|
|
If _<message>_ begins with one or more whitespaces followed
|
|
|
|
|
by "#", it is used as-is. If it begins with "#", a space is
|
|
|
|
|
prepended before it is used. Otherwise, a string " # " (a
|
|
|
|
|
space followed by a hash followed by a space) is prepended
|
|
|
|
|
to it. And the resulting string is placed immediately after
|
|
|
|
|
the value defined for the variable. The _<message>_ must
|
|
|
|
|
not contain linefeed characters (no multi-line comments are
|
|
|
|
|
permitted).
|
2024-03-12 21:47:00 +00:00
|
|
|
|
2024-05-06 08:56:29 +00:00
|
|
|
--all::
|
|
|
|
|
With `get`, return all values for a multi-valued key.
|
2007-01-29 00:16:53 +00:00
|
|
|
|
2024-05-06 08:56:29 +00:00
|
|
|
---regexp::
|
|
|
|
|
With `get`, interpret the name as a regular expression. 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
|
|
|
|
2024-05-06 08:56:29 +00:00
|
|
|
--url=<URL>::
|
2023-12-25 21:21:27 +00:00
|
|
|
When given a two-part <name> as <section>.<key>, the value for
|
|
|
|
|
<section>.<URL>.<key> whose <URL> part matches the best to the
|
2013-07-31 18:14:59 +00:00
|
|
|
given URL is returned (if no such key exists, the value for
|
2023-12-25 21:21:27 +00:00
|
|
|
<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.
|
2019-03-06 06:30:18 +00:00
|
|
|
This is the default behavior.
|
2013-06-17 13:31:31 +00:00
|
|
|
+
|
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::
|
2022-02-07 21:32:58 +00:00
|
|
|
Similar to `--local` except that `$GIT_DIR/config.worktree` is
|
2018-10-21 14:02:28 +00:00
|
|
|
read from or written to if `extensions.worktreeConfig` is
|
2022-02-07 21:32:58 +00:00
|
|
|
enabled. If not it's the same as `--local`. Note that `$GIT_DIR`
|
|
|
|
|
is equal to `$GIT_COMMON_DIR` for the main working tree, but is of
|
|
|
|
|
the form `$GIT_DIR/worktrees/<id>/` for other working trees. See
|
|
|
|
|
linkgit:git-worktree[1] to learn how to enable
|
|
|
|
|
`extensions.worktreeConfig`.
|
2018-10-21 14:02:28 +00:00
|
|
|
|
2021-11-06 18:48:51 +00:00
|
|
|
-f <config-file>::
|
|
|
|
|
--file <config-file>::
|
2021-07-14 21:37:29 +00:00
|
|
|
For writing options: write to the specified file rather than the
|
|
|
|
|
repository `.git/config`.
|
|
|
|
|
+
|
|
|
|
|
For reading options: read only from the specified file rather than from all
|
|
|
|
|
available files.
|
|
|
|
|
+
|
|
|
|
|
See also <<FILES>>.
|
2007-07-31 09:58:43 +00:00
|
|
|
|
2021-11-06 18:48:51 +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.
|
|
|
|
|
|
2020-11-25 22:12:53 +00:00
|
|
|
--fixed-value::
|
|
|
|
|
When used with the `value-pattern` argument, treat `value-pattern` as
|
|
|
|
|
an exact string instead of a regular expression. This will restrict
|
|
|
|
|
the name/value pairs that are matched to only those where the value
|
|
|
|
|
is exactly equal to the `value-pattern`.
|
|
|
|
|
|
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.
|
2023-09-15 20:24:59 +00:00
|
|
|
- 'path': canonicalize by expanding a leading `~` to the value of `$HOME` and
|
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
|
|
|
`~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::
|
builtin/config: introduce "list" subcommand
While git-config(1) has several modes, those modes are not exposed with
subcommands but instead by specifying action flags like `--unset` or
`--list`. This user interface is not really in line with how our more
modern commands work, where it is a lot more customary to say e.g. `git
remote list`. Furthermore, to add to the confusion, git-config(1) also
allows the user to request modes implicitly by just specifying the
correct number of arguments. Thus, `git config foo.bar` will retrieve
the value of "foo.bar" while `git config foo.bar baz` will set it to
"baz".
Overall, this makes for a confusing interface that could really use a
makeover. It hurts discoverability of what you can do with git-config(1)
and is comparatively easy to get wrong. Converting the command to have
subcommands instead would go a long way to help address these issues.
One concern in this context is backwards compatibility. Luckily, we can
introduce subcommands without breaking backwards compatibility at all.
This is because all the implicit modes of git-config(1) require that the
first argument is a properly formatted config key. And as config keys
_must_ have a dot in their name, any value without a dot would have been
discarded by git-config(1) previous to this change. Thus, given that
none of the subcommands do have a dot, they are unambiguous.
Introduce the first such new subcommand, which is "git config list". To
retain backwards compatibility we only conditionally use subcommands and
will fall back to the old syntax in case no subcommand was detected.
This should help to transition to the new-style syntax until we
eventually deprecate and remove the old-style syntax.
Note that the way we handle this we're duplicating some functionality
across old and new syntax. While this isn't pretty, it helps us to
ensure that there really is no change in behaviour for the old syntax.
Amend tests such that we run them both with old and new style syntax.
As tests are now run twice, state from the first run may be still be
around in the second run and thus cause tests to fail. Add cleanup logic
as required to fix such tests.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-05-06 08:56:24 +00:00
|
|
|
Output only the names of config variables for `list` or
|
2024-05-06 08:56:29 +00:00
|
|
|
`get`.
|
2015-08-10 09:46:06 +00:00
|
|
|
|
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).
|
|
|
|
|
|
2020-02-10 00:30:59 +00:00
|
|
|
--show-scope::
|
|
|
|
|
Similar to `--show-origin` in that it augments the output of
|
|
|
|
|
all queried config options with the scope of that value
|
2022-06-07 21:24:04 +00:00
|
|
|
(worktree, local, global, system, command).
|
2020-02-10 00:30:59 +00:00
|
|
|
|
2021-11-06 18:48:51 +00:00
|
|
|
--get-colorbool <name> [<stdout-is-tty>]::
|
2007-12-06 01:26:11 +00:00
|
|
|
|
2021-11-06 18:48:51 +00:00
|
|
|
Find the color setting for `<name>` (e.g. `color.diff`) and output
|
|
|
|
|
"true" or "false". `<stdout-is-tty>` should be either "true" or
|
2007-12-06 01:26:11 +00:00
|
|
|
"false", and is taken into account when configuration says
|
2021-11-06 18:48:51 +00:00
|
|
|
"auto". If `<stdout-is-tty>` is missing, then checks the standard
|
2007-12-06 01:26:11 +00:00
|
|
|
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
|
|
|
|
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>::
|
2024-05-06 08:56:29 +00:00
|
|
|
When using `get`, and the requested variable is not found, behave as if
|
2024-03-16 05:01:25 +00:00
|
|
|
<value> were the value assigned to that variable.
|
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
|
|
|
|
builtin/config: introduce "list" subcommand
While git-config(1) has several modes, those modes are not exposed with
subcommands but instead by specifying action flags like `--unset` or
`--list`. This user interface is not really in line with how our more
modern commands work, where it is a lot more customary to say e.g. `git
remote list`. Furthermore, to add to the confusion, git-config(1) also
allows the user to request modes implicitly by just specifying the
correct number of arguments. Thus, `git config foo.bar` will retrieve
the value of "foo.bar" while `git config foo.bar baz` will set it to
"baz".
Overall, this makes for a confusing interface that could really use a
makeover. It hurts discoverability of what you can do with git-config(1)
and is comparatively easy to get wrong. Converting the command to have
subcommands instead would go a long way to help address these issues.
One concern in this context is backwards compatibility. Luckily, we can
introduce subcommands without breaking backwards compatibility at all.
This is because all the implicit modes of git-config(1) require that the
first argument is a properly formatted config key. And as config keys
_must_ have a dot in their name, any value without a dot would have been
discarded by git-config(1) previous to this change. Thus, given that
none of the subcommands do have a dot, they are unambiguous.
Introduce the first such new subcommand, which is "git config list". To
retain backwards compatibility we only conditionally use subcommands and
will fall back to the old syntax in case no subcommand was detected.
This should help to transition to the new-style syntax until we
eventually deprecate and remove the old-style syntax.
Note that the way we handle this we're duplicating some functionality
across old and new syntax. While this isn't pretty, it helps us to
ensure that there really is no change in behaviour for the old syntax.
Amend tests such that we run them both with old and new style syntax.
As tests are now run twice, state from the first run may be still be
around in the second run and thus cause tests to fail. Add cleanup logic
as required to fix such tests.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-05-06 08:56:24 +00:00
|
|
|
DEPRECATED MODES
|
|
|
|
|
----------------
|
|
|
|
|
|
|
|
|
|
The following modes have been deprecated in favor of subcommands. It is
|
|
|
|
|
recommended to migrate to the new syntax.
|
|
|
|
|
|
2024-05-06 08:56:29 +00:00
|
|
|
'git config <name>'::
|
|
|
|
|
Replaced by `git config get <name>`.
|
|
|
|
|
|
2024-05-06 08:56:33 +00:00
|
|
|
'git config <name> <value> [<value-pattern>]'::
|
|
|
|
|
Replaced by `git config set [--value=<pattern>] <name> <value>`.
|
|
|
|
|
|
builtin/config: introduce "list" subcommand
While git-config(1) has several modes, those modes are not exposed with
subcommands but instead by specifying action flags like `--unset` or
`--list`. This user interface is not really in line with how our more
modern commands work, where it is a lot more customary to say e.g. `git
remote list`. Furthermore, to add to the confusion, git-config(1) also
allows the user to request modes implicitly by just specifying the
correct number of arguments. Thus, `git config foo.bar` will retrieve
the value of "foo.bar" while `git config foo.bar baz` will set it to
"baz".
Overall, this makes for a confusing interface that could really use a
makeover. It hurts discoverability of what you can do with git-config(1)
and is comparatively easy to get wrong. Converting the command to have
subcommands instead would go a long way to help address these issues.
One concern in this context is backwards compatibility. Luckily, we can
introduce subcommands without breaking backwards compatibility at all.
This is because all the implicit modes of git-config(1) require that the
first argument is a properly formatted config key. And as config keys
_must_ have a dot in their name, any value without a dot would have been
discarded by git-config(1) previous to this change. Thus, given that
none of the subcommands do have a dot, they are unambiguous.
Introduce the first such new subcommand, which is "git config list". To
retain backwards compatibility we only conditionally use subcommands and
will fall back to the old syntax in case no subcommand was detected.
This should help to transition to the new-style syntax until we
eventually deprecate and remove the old-style syntax.
Note that the way we handle this we're duplicating some functionality
across old and new syntax. While this isn't pretty, it helps us to
ensure that there really is no change in behaviour for the old syntax.
Amend tests such that we run them both with old and new style syntax.
As tests are now run twice, state from the first run may be still be
around in the second run and thus cause tests to fail. Add cleanup logic
as required to fix such tests.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-05-06 08:56:24 +00:00
|
|
|
-l::
|
|
|
|
|
--list::
|
|
|
|
|
Replaced by `git config list`.
|
|
|
|
|
|
2024-05-06 08:56:29 +00:00
|
|
|
--get <name> [<value-pattern>]::
|
|
|
|
|
Replaced by `git config get [--value=<pattern>] <name>`.
|
|
|
|
|
|
|
|
|
|
--get-all <name> [<value-pattern>]::
|
|
|
|
|
Replaced by `git config get [--value=<pattern>] --all --show-names <name>`.
|
|
|
|
|
|
|
|
|
|
--get-regexp <name-regexp>::
|
|
|
|
|
Replaced by `git config get --all --show-names --regexp <name-regexp>`.
|
|
|
|
|
|
|
|
|
|
--get-urlmatch <name> <URL>::
|
|
|
|
|
Replaced by `git config get --all --show-names --url=<URL> <name>`.
|
|
|
|
|
|
|
|
|
|
--get-color <name> [<default>]::
|
|
|
|
|
Replaced by `git config get --type=color [--default=<default>] <name>`.
|
|
|
|
|
|
2024-05-06 08:56:33 +00:00
|
|
|
--add <name> <value>::
|
|
|
|
|
Replaced by `git config set --append <name> <value>`.
|
|
|
|
|
|
2024-05-06 08:56:38 +00:00
|
|
|
--unset <name> [<value-pattern>]::
|
|
|
|
|
Replaced by `git config unset [--value=<pattern>] <name>`.
|
|
|
|
|
|
|
|
|
|
--unset-all <name> [<value-pattern>]::
|
|
|
|
|
Replaced by `git config unset [--value=<pattern>] --all <name>`.
|
|
|
|
|
|
2024-05-06 08:56:43 +00:00
|
|
|
--rename-section <old-name> <new-name>::
|
|
|
|
|
Replaced by `git config rename-section <old-name> <new-name>`.
|
|
|
|
|
|
2024-05-06 08:56:47 +00:00
|
|
|
--remove-section <name>::
|
|
|
|
|
Replaced by `git config remove-section <name>`.
|
|
|
|
|
|
2024-05-06 08:56:52 +00:00
|
|
|
-e::
|
|
|
|
|
--edit::
|
|
|
|
|
Replaced by `git config edit`.
|
|
|
|
|
|
2018-02-21 18:51:43 +00:00
|
|
|
CONFIGURATION
|
|
|
|
|
-------------
|
|
|
|
|
`pager.config` is only respected when listing configuration, i.e., when
|
2024-05-06 08:56:29 +00:00
|
|
|
using `list` or `get` which may return multiple results. 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
|
|
|
|
|
-----
|
|
|
|
|
|
Documentation/git-config.txt: add SCOPES section
In a subsequent commit, we will introduce "protected configuration",
which is easiest to describe in terms of configuration scopes (i.e. it's
the union of the 'system', 'global', and 'command' scopes). This
description is fine for ML discussions, but it's inadequate for end
users because we don't provide a good description of "configuration
scopes" in the public docs.
145d59f482 (config: add '--show-scope' to print the scope of a config
value, 2020-02-10) introduced the word "scope" to our public docs, but
that only enumerates the scopes and assumes the user can figure out
what those values mean.
Add a SCOPES section to Documentation/git-config.txt that describes the
configuration scopes, their corresponding CLI options, and mentions that
some configuration options are only respected in certain scopes. Then,
use the word "scope" to simplify the FILES section and change some
confusing wording.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:57 +00:00
|
|
|
By default, 'git config' will read configuration options from multiple
|
|
|
|
|
files:
|
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::
|
2013-07-07 19:49:56 +00:00
|
|
|
~/.gitconfig::
|
Documentation/git-config.txt: add SCOPES section
In a subsequent commit, we will introduce "protected configuration",
which is easiest to describe in terms of configuration scopes (i.e. it's
the union of the 'system', 'global', and 'command' scopes). This
description is fine for ML discussions, but it's inadequate for end
users because we don't provide a good description of "configuration
scopes" in the public docs.
145d59f482 (config: add '--show-scope' to print the scope of a config
value, 2020-02-10) introduced the word "scope" to our public docs, but
that only enumerates the scopes and assumes the user can figure out
what those values mean.
Add a SCOPES section to Documentation/git-config.txt that describes the
configuration scopes, their corresponding CLI options, and mentions that
some configuration options are only respected in certain scopes. Then,
use the word "scope" to simplify the FILES section and change some
confusing wording.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:57 +00:00
|
|
|
User-specific configuration files. When the XDG_CONFIG_HOME environment
|
|
|
|
|
variable is not set or empty, $HOME/.config/ is used as
|
|
|
|
|
$XDG_CONFIG_HOME.
|
|
|
|
|
+
|
|
|
|
|
These are also called "global" configuration files. If both files exist, both
|
|
|
|
|
files are read in the order given above.
|
2013-07-07 19:49:56 +00:00
|
|
|
|
|
|
|
|
$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.
|
|
|
|
|
|
Documentation/git-config.txt: add SCOPES section
In a subsequent commit, we will introduce "protected configuration",
which is easiest to describe in terms of configuration scopes (i.e. it's
the union of the 'system', 'global', and 'command' scopes). This
description is fine for ML discussions, but it's inadequate for end
users because we don't provide a good description of "configuration
scopes" in the public docs.
145d59f482 (config: add '--show-scope' to print the scope of a config
value, 2020-02-10) introduced the word "scope" to our public docs, but
that only enumerates the scopes and assumes the user can figure out
what those values mean.
Add a SCOPES section to Documentation/git-config.txt that describes the
configuration scopes, their corresponding CLI options, and mentions that
some configuration options are only respected in certain scopes. Then,
use the word "scope" to simplify the FILES section and change some
confusing wording.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:57 +00:00
|
|
|
You may also provide additional configuration parameters when running any
|
|
|
|
|
git command by using the `-c` option. See linkgit:git[1] for details.
|
|
|
|
|
|
|
|
|
|
Options will be read from all of these files that are available. If the
|
|
|
|
|
global or the system-wide configuration files are missing or unreadable they
|
|
|
|
|
will be ignored. If the repository configuration file is missing or unreadable,
|
|
|
|
|
'git config' will exit with a non-zero error code. An error message is produced
|
|
|
|
|
if the file is unreadable, but not if it is missing.
|
2007-05-31 00:35:37 +00:00
|
|
|
|
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.
|
|
|
|
|
|
Documentation/git-config.txt: add SCOPES section
In a subsequent commit, we will introduce "protected configuration",
which is easiest to describe in terms of configuration scopes (i.e. it's
the union of the 'system', 'global', and 'command' scopes). This
description is fine for ML discussions, but it's inadequate for end
users because we don't provide a good description of "configuration
scopes" in the public docs.
145d59f482 (config: add '--show-scope' to print the scope of a config
value, 2020-02-10) introduced the word "scope" to our public docs, but
that only enumerates the scopes and assumes the user can figure out
what those values mean.
Add a SCOPES section to Documentation/git-config.txt that describes the
configuration scopes, their corresponding CLI options, and mentions that
some configuration options are only respected in certain scopes. Then,
use the word "scope" to simplify the FILES section and change some
confusing wording.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:57 +00:00
|
|
|
By default, options are only written to the repository specific
|
2024-05-06 08:56:33 +00:00
|
|
|
configuration file. Note that this also affects options like `set`
|
2024-05-06 08:56:38 +00:00
|
|
|
and `unset`. *'git config' will only ever change one file at a time*.
|
2007-05-31 00:35:37 +00:00
|
|
|
|
Documentation/git-config.txt: add SCOPES section
In a subsequent commit, we will introduce "protected configuration",
which is easiest to describe in terms of configuration scopes (i.e. it's
the union of the 'system', 'global', and 'command' scopes). This
description is fine for ML discussions, but it's inadequate for end
users because we don't provide a good description of "configuration
scopes" in the public docs.
145d59f482 (config: add '--show-scope' to print the scope of a config
value, 2020-02-10) introduced the word "scope" to our public docs, but
that only enumerates the scopes and assumes the user can figure out
what those values mean.
Add a SCOPES section to Documentation/git-config.txt that describes the
configuration scopes, their corresponding CLI options, and mentions that
some configuration options are only respected in certain scopes. Then,
use the word "scope" to simplify the FILES section and change some
confusing wording.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:57 +00:00
|
|
|
You can limit which configuration sources are read from or written to by
|
|
|
|
|
specifying the path of a file with the `--file` option, or by specifying a
|
|
|
|
|
configuration scope with `--system`, `--global`, `--local`, or `--worktree`.
|
|
|
|
|
For more, see <<OPTIONS>> above.
|
|
|
|
|
|
Documentation: define protected configuration
For security reasons, there are config variables that are only trusted
when they are specified in certain configuration scopes, which are
sometimes referred to on-list as 'protected configuration' [1]. A future
commit will introduce another such variable, so let's define our terms
so that we can have consistent documentation and implementation.
In our documentation, define 'protected configuration' as the system,
global and command config scopes. As a shorthand, I will refer to
variables that are only respected in protected configuration as
'protected configuration only', but this term is not used in the
documentation.
This definition of protected configuration is based on whether or not
Git can reasonably protect the user by ignoring the configuration scope:
- System, global and command line config are considered protected
because an attacker who has control over any of those can do plenty of
harm without Git, so we gain very little by ignoring those scopes.
- On the other hand, local (and similarly, worktree) config are not
considered protected because it is relatively easy for an attacker to
control local config, e.g.:
- On some shared user environments, a non-admin attacker can create a
repository high up the directory hierarchy (e.g. C:\.git on
Windows), and a user may accidentally use it when their PS1
automatically invokes "git" commands.
`safe.directory` prevents attacks of this form by making sure that
the user intended to use the shared repository. It obviously
shouldn't be read from the repository, because that would end up
trusting the repository that Git was supposed to reject.
- "git upload-pack" is expected to run in repositories that may not be
controlled by the user. We cannot ignore all config in that
repository (because "git upload-pack" would fail), but we can limit
the risks by ignoring `uploadpack.packObjectsHook`.
Only `uploadpack.packObjectsHook` is 'protected configuration only'. The
following variables are intentionally excluded:
- `safe.directory` should be 'protected configuration only', but it does
not technically fit the definition because it is not respected in the
"command" scope. A future commit will fix this.
- `trace2.*` happens to read the same scopes as `safe.directory` because
they share an implementation. However, this is not for security
reasons; it is because we want to start tracing so early that
repository-level config and "-c" are not available [2].
This requirement is unique to `trace2.*`, so it does not makes sense
for protected configuration to be subject to the same constraints.
[1] For example,
https://lore.kernel.org/git/6af83767-576b-75c4-c778-0284344a8fe7@github.com/
[2] https://lore.kernel.org/git/a0c89d0d-669e-bf56-25d2-cbb09b012e70@jeffhostetler.com/
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:58 +00:00
|
|
|
[[SCOPES]]
|
Documentation/git-config.txt: add SCOPES section
In a subsequent commit, we will introduce "protected configuration",
which is easiest to describe in terms of configuration scopes (i.e. it's
the union of the 'system', 'global', and 'command' scopes). This
description is fine for ML discussions, but it's inadequate for end
users because we don't provide a good description of "configuration
scopes" in the public docs.
145d59f482 (config: add '--show-scope' to print the scope of a config
value, 2020-02-10) introduced the word "scope" to our public docs, but
that only enumerates the scopes and assumes the user can figure out
what those values mean.
Add a SCOPES section to Documentation/git-config.txt that describes the
configuration scopes, their corresponding CLI options, and mentions that
some configuration options are only respected in certain scopes. Then,
use the word "scope" to simplify the FILES section and change some
confusing wording.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:57 +00:00
|
|
|
SCOPES
|
|
|
|
|
------
|
|
|
|
|
|
|
|
|
|
Each configuration source falls within a configuration scope. The scopes
|
|
|
|
|
are:
|
|
|
|
|
|
|
|
|
|
system::
|
|
|
|
|
$(prefix)/etc/gitconfig
|
|
|
|
|
|
|
|
|
|
global::
|
|
|
|
|
$XDG_CONFIG_HOME/git/config
|
|
|
|
|
+
|
|
|
|
|
~/.gitconfig
|
|
|
|
|
|
|
|
|
|
local::
|
|
|
|
|
$GIT_DIR/config
|
|
|
|
|
|
|
|
|
|
worktree::
|
|
|
|
|
$GIT_DIR/config.worktree
|
|
|
|
|
|
|
|
|
|
command::
|
|
|
|
|
GIT_CONFIG_{COUNT,KEY,VALUE} environment variables (see <<ENVIRONMENT>>
|
|
|
|
|
below)
|
|
|
|
|
+
|
|
|
|
|
the `-c` option
|
|
|
|
|
|
|
|
|
|
With the exception of 'command', each scope corresponds to a command line
|
|
|
|
|
option: `--system`, `--global`, `--local`, `--worktree`.
|
|
|
|
|
|
|
|
|
|
When reading options, specifying a scope will only read options from the
|
|
|
|
|
files within that scope. When writing options, specifying a scope will write
|
|
|
|
|
to the files within that scope (instead of the repository specific
|
|
|
|
|
configuration file). See <<OPTIONS>> above for a complete description.
|
2007-05-31 00:35:37 +00:00
|
|
|
|
Documentation/git-config.txt: add SCOPES section
In a subsequent commit, we will introduce "protected configuration",
which is easiest to describe in terms of configuration scopes (i.e. it's
the union of the 'system', 'global', and 'command' scopes). This
description is fine for ML discussions, but it's inadequate for end
users because we don't provide a good description of "configuration
scopes" in the public docs.
145d59f482 (config: add '--show-scope' to print the scope of a config
value, 2020-02-10) introduced the word "scope" to our public docs, but
that only enumerates the scopes and assumes the user can figure out
what those values mean.
Add a SCOPES section to Documentation/git-config.txt that describes the
configuration scopes, their corresponding CLI options, and mentions that
some configuration options are only respected in certain scopes. Then,
use the word "scope" to simplify the FILES section and change some
confusing wording.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:57 +00:00
|
|
|
Most configuration options are respected regardless of the scope it is
|
|
|
|
|
defined in, but some options are only respected in certain scopes. See the
|
|
|
|
|
respective option's documentation for the full details.
|
2007-05-31 00:35:37 +00:00
|
|
|
|
Documentation: define protected configuration
For security reasons, there are config variables that are only trusted
when they are specified in certain configuration scopes, which are
sometimes referred to on-list as 'protected configuration' [1]. A future
commit will introduce another such variable, so let's define our terms
so that we can have consistent documentation and implementation.
In our documentation, define 'protected configuration' as the system,
global and command config scopes. As a shorthand, I will refer to
variables that are only respected in protected configuration as
'protected configuration only', but this term is not used in the
documentation.
This definition of protected configuration is based on whether or not
Git can reasonably protect the user by ignoring the configuration scope:
- System, global and command line config are considered protected
because an attacker who has control over any of those can do plenty of
harm without Git, so we gain very little by ignoring those scopes.
- On the other hand, local (and similarly, worktree) config are not
considered protected because it is relatively easy for an attacker to
control local config, e.g.:
- On some shared user environments, a non-admin attacker can create a
repository high up the directory hierarchy (e.g. C:\.git on
Windows), and a user may accidentally use it when their PS1
automatically invokes "git" commands.
`safe.directory` prevents attacks of this form by making sure that
the user intended to use the shared repository. It obviously
shouldn't be read from the repository, because that would end up
trusting the repository that Git was supposed to reject.
- "git upload-pack" is expected to run in repositories that may not be
controlled by the user. We cannot ignore all config in that
repository (because "git upload-pack" would fail), but we can limit
the risks by ignoring `uploadpack.packObjectsHook`.
Only `uploadpack.packObjectsHook` is 'protected configuration only'. The
following variables are intentionally excluded:
- `safe.directory` should be 'protected configuration only', but it does
not technically fit the definition because it is not respected in the
"command" scope. A future commit will fix this.
- `trace2.*` happens to read the same scopes as `safe.directory` because
they share an implementation. However, this is not for security
reasons; it is because we want to start tracing so early that
repository-level config and "-c" are not available [2].
This requirement is unique to `trace2.*`, so it does not makes sense
for protected configuration to be subject to the same constraints.
[1] For example,
https://lore.kernel.org/git/6af83767-576b-75c4-c778-0284344a8fe7@github.com/
[2] https://lore.kernel.org/git/a0c89d0d-669e-bf56-25d2-cbb09b012e70@jeffhostetler.com/
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:58 +00:00
|
|
|
Protected configuration
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Protected configuration refers to the 'system', 'global', and 'command' scopes.
|
|
|
|
|
For security reasons, certain options are only respected when they are
|
|
|
|
|
specified in protected configuration, and ignored otherwise.
|
|
|
|
|
|
|
|
|
|
Git treats these scopes as if they are controlled by the user or a trusted
|
|
|
|
|
administrator. This is because an attacker who controls these scopes can do
|
|
|
|
|
substantial harm without using Git, so it is assumed that the user's environment
|
|
|
|
|
protects these scopes against attackers.
|
|
|
|
|
|
Documentation/git-config.txt: add SCOPES section
In a subsequent commit, we will introduce "protected configuration",
which is easiest to describe in terms of configuration scopes (i.e. it's
the union of the 'system', 'global', and 'command' scopes). This
description is fine for ML discussions, but it's inadequate for end
users because we don't provide a good description of "configuration
scopes" in the public docs.
145d59f482 (config: add '--show-scope' to print the scope of a config
value, 2020-02-10) introduced the word "scope" to our public docs, but
that only enumerates the scopes and assumes the user can figure out
what those values mean.
Add a SCOPES section to Documentation/git-config.txt that describes the
configuration scopes, their corresponding CLI options, and mentions that
some configuration options are only respected in certain scopes. Then,
use the word "scope" to simplify the FILES section and change some
confusing wording.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:57 +00:00
|
|
|
[[ENVIRONMENT]]
|
2007-01-29 00:16:53 +00:00
|
|
|
ENVIRONMENT
|
|
|
|
|
-----------
|
|
|
|
|
|
config: allow overriding of global and system configuration
In order to have git run in a fully controlled environment without any
misconfiguration, it may be desirable for users or scripts to override
global- and system-level configuration files. We already have a way of
doing this, which is to unset both HOME and XDG_CONFIG_HOME environment
variables and to set `GIT_CONFIG_NOGLOBAL=true`. This is quite kludgy,
and unsetting the first two variables likely has an impact on other
executables spawned by such a script.
The obvious way to fix this would be to introduce `GIT_CONFIG_NOGLOBAL`
as an equivalent to `GIT_CONFIG_NOSYSTEM`. But in the past, it has
turned out that this design is inflexible: we cannot test system-level
parsing of the git configuration in our test harness because there is no
way to change its location, so all tests run with `GIT_CONFIG_NOSYSTEM`
set.
Instead of doing the same mistake with `GIT_CONFIG_NOGLOBAL`, introduce
two new variables `GIT_CONFIG_GLOBAL` and `GIT_CONFIG_SYSTEM`:
- If unset, git continues to use the usual locations.
- If set to a specific path, we skip reading the normal
configuration files and instead take the path. By setting the path
to `/dev/null`, no configuration will be loaded for the respective
level.
This implements the usecase where we want to execute code in a sanitized
environment without any potential misconfigurations via `/dev/null`, but
is more flexible and allows for more usecases than simply adding
`GIT_CONFIG_NOGLOBAL`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-19 12:31:16 +00:00
|
|
|
GIT_CONFIG_GLOBAL::
|
|
|
|
|
GIT_CONFIG_SYSTEM::
|
|
|
|
|
Take the configuration from the given files instead from global or
|
|
|
|
|
system-level configuration. See linkgit:git[1] for details.
|
|
|
|
|
|
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
|
|
|
|
2021-01-12 12:27:14 +00:00
|
|
|
GIT_CONFIG_COUNT::
|
|
|
|
|
GIT_CONFIG_KEY_<n>::
|
|
|
|
|
GIT_CONFIG_VALUE_<n>::
|
|
|
|
|
If GIT_CONFIG_COUNT is set to a positive number, all environment pairs
|
|
|
|
|
GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be
|
|
|
|
|
added to the process's runtime configuration. The config pairs are
|
|
|
|
|
zero-indexed. Any missing key or value is treated as an error. An empty
|
|
|
|
|
GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no
|
|
|
|
|
pairs are processed. These environment variables will override values
|
|
|
|
|
in configuration files, but will be overridden by any explicit options
|
|
|
|
|
passed via `git -c`.
|
|
|
|
|
+
|
|
|
|
|
This is useful for cases where you want to spawn multiple git commands
|
|
|
|
|
with a common configuration but cannot depend on a configuration file,
|
|
|
|
|
for example when writing scripts.
|
|
|
|
|
|
2021-07-14 21:38:16 +00:00
|
|
|
GIT_CONFIG::
|
|
|
|
|
If no `--file` option is provided to `git config`, use the file
|
|
|
|
|
given by `GIT_CONFIG` as if it were provided via `--file`. This
|
|
|
|
|
variable has no effect on other Git commands, and is mostly for
|
|
|
|
|
historical compatibility; there is generally no reason to use it
|
|
|
|
|
instead of the `--file` option.
|
2007-05-31 00:35:36 +00:00
|
|
|
|
|
|
|
|
[[EXAMPLES]]
|
|
|
|
|
EXAMPLES
|
|
|
|
|
--------
|
2007-01-29 00:16:53 +00:00
|
|
|
|
|
|
|
|
Given a .git/config like this:
|
|
|
|
|
|
2019-09-07 14:12:49 +00:00
|
|
|
------------
|
|
|
|
|
#
|
|
|
|
|
# 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]
|
|
|
|
|
external = /usr/local/bin/diff-wrapper
|
|
|
|
|
renames = true
|
|
|
|
|
|
|
|
|
|
; Proxy settings
|
|
|
|
|
[core]
|
|
|
|
|
gitproxy=proxy-command for kernel.org
|
|
|
|
|
gitproxy=default-proxy ; for all the rest
|
|
|
|
|
|
|
|
|
|
; HTTP
|
|
|
|
|
[http]
|
|
|
|
|
sslVerify
|
|
|
|
|
[http "https://weak.example.com"]
|
|
|
|
|
sslVerify = false
|
|
|
|
|
cookieFile = /tmp/cookie.txt
|
|
|
|
|
------------
|
2013-07-31 18:14:59 +00:00
|
|
|
|
2007-01-29 00:16:53 +00:00
|
|
|
you can set the filemode to true with
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:33 +00:00
|
|
|
% git config set core.filemode true
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
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".
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:33 +00:00
|
|
|
% git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org'
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
This makes sure that only the key/value pair for kernel.org is replaced.
|
|
|
|
|
|
|
|
|
|
To delete the entry for renames, do
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:38 +00:00
|
|
|
% git config unset diff.renames
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:29 +00:00
|
|
|
% git config get core.filemode
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
or, to query a multivar:
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:29 +00:00
|
|
|
% git config get --value="for kernel.org$" core.gitproxy
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
If you want to know all the values for a multivar, do:
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:29 +00:00
|
|
|
% git config get --all --show-names core.gitproxy
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:33 +00:00
|
|
|
% git config set --all core.gitproxy ssh
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:33 +00:00
|
|
|
% git config set --value='! for ' core.gitproxy ssh
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
To actually match only values with an exclamation mark, you have to
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:33 +00:00
|
|
|
% git config set --value='[!]' section.key value
|
2007-01-29 00:16:53 +00:00
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
To add a new proxy, without altering any of the existing ones, use
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:33 +00:00
|
|
|
% git config set --append 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
|
2024-05-06 08:56:29 +00:00
|
|
|
WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace)
|
|
|
|
|
RESET=$(git config get --type=color --default="reset" "")
|
2007-11-28 06:41:05 +00:00
|
|
|
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:
|
|
|
|
|
|
|
|
|
|
------------
|
2024-05-06 08:56:29 +00:00
|
|
|
% git config get --type=bool --url=https://good.example.com http.sslverify
|
2013-07-31 18:14:59 +00:00
|
|
|
true
|
2024-05-06 08:56:29 +00:00
|
|
|
% git config get --type=bool --url=https://weak.example.com http.sslverify
|
2013-07-31 18:14:59 +00:00
|
|
|
false
|
2024-05-06 08:56:29 +00:00
|
|
|
% git config get --url=https://weak.example.com http
|
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
|
