2012-02-06 10:53:46 +01:00
|
|
|
config API
|
|
|
|
==========
|
|
|
|
|
2013-01-21 20:17:53 +01:00
|
|
|
The config API gives callers a way to access Git configuration files
|
2012-06-07 23:03:23 +02:00
|
|
|
(and files which have the same syntax). See linkgit:git-config[1] for a
|
2012-02-06 10:53:46 +01:00
|
|
|
discussion of the config file syntax.
|
|
|
|
|
|
|
|
General Usage
|
|
|
|
-------------
|
|
|
|
|
|
|
|
Config files are parsed linearly, and each variable found is passed to a
|
|
|
|
caller-provided callback function. The callback function is responsible
|
|
|
|
for any actions to be taken on the config option, and is free to ignore
|
2012-02-17 09:18:38 +01:00
|
|
|
some options. It is not uncommon for the configuration to be parsed
|
2013-01-21 20:17:53 +01:00
|
|
|
several times during the run of a Git program, with different callbacks
|
2012-02-17 09:18:38 +01:00
|
|
|
picking out different variables useful to themselves.
|
2012-02-06 10:53:46 +01:00
|
|
|
|
|
|
|
A config callback function takes three parameters:
|
|
|
|
|
|
|
|
- the name of the parsed variable. This is in canonical "flat" form: the
|
|
|
|
section, subsection, and variable segments will be separated by dots,
|
|
|
|
and the section and variable segments will be all lowercase. E.g.,
|
|
|
|
`core.ignorecase`, `diff.SomeType.textconv`.
|
|
|
|
|
|
|
|
- the value of the found variable, as a string. If the variable had no
|
|
|
|
value specified, the value will be NULL (typically this means it
|
|
|
|
should be interpreted as boolean true).
|
|
|
|
|
|
|
|
- a void pointer passed in by the caller of the config API; this can
|
|
|
|
contain callback-specific data
|
|
|
|
|
|
|
|
A config callback should return 0 for success, or -1 if the variable
|
|
|
|
could not be parsed properly.
|
|
|
|
|
|
|
|
Basic Config Querying
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
Most programs will simply want to look up variables in all config files
|
2013-01-21 20:17:53 +01:00
|
|
|
that Git knows about, using the normal precedence rules. To do this,
|
2012-02-06 10:53:46 +01:00
|
|
|
call `git_config` with a callback function and void data pointer.
|
|
|
|
|
|
|
|
`git_config` will read all config sources in order of increasing
|
|
|
|
priority. Thus a callback should typically overwrite previously-seen
|
|
|
|
entries with new ones (e.g., if both the user-wide `~/.gitconfig` and
|
|
|
|
repo-specific `.git/config` contain `color.ui`, the config machinery
|
|
|
|
will first feed the user-wide one to the callback, and then the
|
|
|
|
repo-specific one; by overwriting, the higher-priority repo-specific
|
|
|
|
value is left at the end).
|
|
|
|
|
config: provide a version of git_config with more options
Callers may want to provide a specific version of a file in which to look
for config. Right now this can be done by setting the magic global
config_exclusive_filename variable. By providing a version of git_config
that takes a filename, we can take a step towards making this magic global
go away.
Furthermore, by providing a more "advanced" interface, we now have a a
natural place to add new options for callers like git-config, which care
about tweaking the specifics of config lookup, without disturbing the
large number of "simple" users (i.e., every other part of git).
The astute reader of this patch may notice that the logic for handling
config_exclusive_filename was taken out of git_config_early, but added
into git_config. This means that git_config_early will no longer respect
config_exclusive_filename. That's OK, because the only other caller of
git_config_early is check_repository_format_gently, but the only function
which sets config_exclusive_filename is cmd_config, which does not call
check_repository_format_gently (and if it did, it would have been a bug,
anyway, as we would be checking the repository format in the wrong file).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-16 09:05:56 +01:00
|
|
|
The `git_config_with_options` function lets the caller examine config
|
|
|
|
while adjusting some of the default behavior of `git_config`. It should
|
2013-01-21 20:17:53 +01:00
|
|
|
almost never be used by "regular" Git code that is looking up
|
config: provide a version of git_config with more options
Callers may want to provide a specific version of a file in which to look
for config. Right now this can be done by setting the magic global
config_exclusive_filename variable. By providing a version of git_config
that takes a filename, we can take a step towards making this magic global
go away.
Furthermore, by providing a more "advanced" interface, we now have a a
natural place to add new options for callers like git-config, which care
about tweaking the specifics of config lookup, without disturbing the
large number of "simple" users (i.e., every other part of git).
The astute reader of this patch may notice that the logic for handling
config_exclusive_filename was taken out of git_config_early, but added
into git_config. This means that git_config_early will no longer respect
config_exclusive_filename. That's OK, because the only other caller of
git_config_early is check_repository_format_gently, but the only function
which sets config_exclusive_filename is cmd_config, which does not call
check_repository_format_gently (and if it did, it would have been a bug,
anyway, as we would be checking the repository format in the wrong file).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-16 09:05:56 +01:00
|
|
|
configuration variables. It is intended for advanced callers like
|
|
|
|
`git-config`, which are intentionally tweaking the normal config-lookup
|
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 10:54:04 +01:00
|
|
|
process. It takes two extra parameters:
|
config: provide a version of git_config with more options
Callers may want to provide a specific version of a file in which to look
for config. Right now this can be done by setting the magic global
config_exclusive_filename variable. By providing a version of git_config
that takes a filename, we can take a step towards making this magic global
go away.
Furthermore, by providing a more "advanced" interface, we now have a a
natural place to add new options for callers like git-config, which care
about tweaking the specifics of config lookup, without disturbing the
large number of "simple" users (i.e., every other part of git).
The astute reader of this patch may notice that the logic for handling
config_exclusive_filename was taken out of git_config_early, but added
into git_config. This means that git_config_early will no longer respect
config_exclusive_filename. That's OK, because the only other caller of
git_config_early is check_repository_format_gently, but the only function
which sets config_exclusive_filename is cmd_config, which does not call
check_repository_format_gently (and if it did, it would have been a bug,
anyway, as we would be checking the repository format in the wrong file).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-16 09:05:56 +01:00
|
|
|
|
|
|
|
`filename`::
|
|
|
|
If this parameter is non-NULL, it specifies the name of a file to
|
|
|
|
parse for configuration, rather than looking in the usual files. Regular
|
|
|
|
`git_config` defaults to `NULL`.
|
|
|
|
|
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 10:54:04 +01:00
|
|
|
`respect_includes`::
|
|
|
|
Specify whether include directives should be followed in parsed files.
|
|
|
|
Regular `git_config` defaults to `1`.
|
|
|
|
|
2012-02-06 10:53:46 +01:00
|
|
|
Reading Specific Files
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
To read a specific file in git-config format, use
|
|
|
|
`git_config_from_file`. This takes the same callback and data parameters
|
|
|
|
as `git_config`.
|
|
|
|
|
2014-07-28 12:10:38 +02:00
|
|
|
Querying For Specific Variables
|
|
|
|
-------------------------------
|
|
|
|
|
|
|
|
For programs wanting to query for specific variables in a non-callback
|
|
|
|
manner, the config API provides two functions `git_config_get_value`
|
|
|
|
and `git_config_get_value_multi`. They both read values from an internal
|
|
|
|
cache generated previously from reading the config files.
|
|
|
|
|
|
|
|
`int git_config_get_value(const char *key, const char **value)`::
|
|
|
|
|
|
|
|
Finds the highest-priority value for the configuration variable `key`,
|
|
|
|
stores the pointer to it in `value` and returns 0. When the
|
|
|
|
configuration variable `key` is not found, returns 1 without touching
|
|
|
|
`value`. The caller should not free or modify `value`, as it is owned
|
|
|
|
by the cache.
|
|
|
|
|
|
|
|
`const struct string_list *git_config_get_value_multi(const char *key)`::
|
|
|
|
|
|
|
|
Finds and returns the value list, sorted in order of increasing priority
|
|
|
|
for the configuration variable `key`. When the configuration variable
|
|
|
|
`key` is not found, returns NULL. The caller should not free or modify
|
|
|
|
the returned pointer, as it is owned by the cache.
|
|
|
|
|
|
|
|
`void git_config_clear(void)`::
|
|
|
|
|
|
|
|
Resets and invalidates the config cache.
|
|
|
|
|
|
|
|
The config API also provides type specific API functions which do conversion
|
|
|
|
as well as retrieval for the queried variable, including:
|
|
|
|
|
|
|
|
`int git_config_get_int(const char *key, int *dest)`::
|
|
|
|
|
|
|
|
Finds and parses the value to an integer for the configuration variable
|
|
|
|
`key`. Dies on error; otherwise, stores the value of the parsed integer in
|
|
|
|
`dest` and returns 0. When the configuration variable `key` is not found,
|
|
|
|
returns 1 without touching `dest`.
|
|
|
|
|
|
|
|
`int git_config_get_ulong(const char *key, unsigned long *dest)`::
|
|
|
|
|
|
|
|
Similar to `git_config_get_int` but for unsigned longs.
|
|
|
|
|
|
|
|
`int git_config_get_bool(const char *key, int *dest)`::
|
|
|
|
|
|
|
|
Finds and parses the value into a boolean value, for the configuration
|
|
|
|
variable `key` respecting keywords like "true" and "false". Integer
|
|
|
|
values are converted into true/false values (when they are non-zero or
|
|
|
|
zero, respectively). Other values cause a die(). If parsing is successful,
|
|
|
|
stores the value of the parsed result in `dest` and returns 0. When the
|
|
|
|
configuration variable `key` is not found, returns 1 without touching
|
|
|
|
`dest`.
|
|
|
|
|
|
|
|
`int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest)`::
|
|
|
|
|
|
|
|
Similar to `git_config_get_bool`, except that integers are copied as-is,
|
|
|
|
and `is_bool` flag is unset.
|
|
|
|
|
|
|
|
`int git_config_get_maybe_bool(const char *key, int *dest)`::
|
|
|
|
|
|
|
|
Similar to `git_config_get_bool`, except that it returns -1 on error
|
|
|
|
rather than dying.
|
|
|
|
|
|
|
|
`int git_config_get_string_const(const char *key, const char **dest)`::
|
|
|
|
|
|
|
|
Allocates and copies the retrieved string into the `dest` parameter for
|
|
|
|
the configuration variable `key`; if NULL string is given, prints an
|
|
|
|
error message and returns -1. When the configuration variable `key` is
|
|
|
|
not found, returns 1 without touching `dest`.
|
|
|
|
|
|
|
|
`int git_config_get_string(const char *key, char **dest)`::
|
|
|
|
|
|
|
|
Similar to `git_config_get_string_const`, except that retrieved value
|
|
|
|
copied into the `dest` parameter is a mutable string.
|
|
|
|
|
|
|
|
`int git_config_get_pathname(const char *key, const char **dest)`::
|
|
|
|
|
|
|
|
Similar to `git_config_get_string`, but expands `~` or `~user` into
|
|
|
|
the user's home directory when found at the beginning of the path.
|
|
|
|
|
2014-08-07 13:59:16 +02:00
|
|
|
`git_die_config(const char *key, const char *err, ...)`::
|
|
|
|
|
|
|
|
First prints the error message specified by the caller in `err` and then
|
|
|
|
dies printing the line number and the file name of the highest priority
|
|
|
|
value for the configuration variable `key`.
|
|
|
|
|
|
|
|
`void git_die_config_linenr(const char *key, const char *filename, int linenr)`::
|
|
|
|
|
|
|
|
Helper function which formats the die error message according to the
|
|
|
|
parameters entered. Used by `git_die_config()`. It can be used by callers
|
|
|
|
handling `git_config_get_value_multi()` to print the correct error message
|
|
|
|
for the desired value.
|
|
|
|
|
2014-07-28 12:10:38 +02:00
|
|
|
See test-config.c for usage examples.
|
|
|
|
|
2012-02-06 10:53:46 +01:00
|
|
|
Value Parsing Helpers
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
To aid in parsing string values, the config API provides callbacks with
|
|
|
|
a number of helper functions, including:
|
|
|
|
|
|
|
|
`git_config_int`::
|
|
|
|
Parse the string to an integer, including unit factors. Dies on error;
|
|
|
|
otherwise, returns the parsed result.
|
|
|
|
|
|
|
|
`git_config_ulong`::
|
|
|
|
Identical to `git_config_int`, but for unsigned longs.
|
|
|
|
|
|
|
|
`git_config_bool`::
|
|
|
|
Parse a string into a boolean value, respecting keywords like "true" and
|
|
|
|
"false". Integer values are converted into true/false values (when they
|
|
|
|
are non-zero or zero, respectively). Other values cause a die(). If
|
|
|
|
parsing is successful, the return value is the result.
|
|
|
|
|
|
|
|
`git_config_bool_or_int`::
|
|
|
|
Same as `git_config_bool`, except that integers are returned as-is, and
|
|
|
|
an `is_bool` flag is unset.
|
|
|
|
|
|
|
|
`git_config_maybe_bool`::
|
|
|
|
Same as `git_config_bool`, except that it returns -1 on error rather
|
|
|
|
than dying.
|
|
|
|
|
|
|
|
`git_config_string`::
|
|
|
|
Allocates and copies the value string into the `dest` parameter; if no
|
|
|
|
string is given, prints an error message and returns -1.
|
|
|
|
|
|
|
|
`git_config_pathname`::
|
|
|
|
Similar to `git_config_string`, but expands `~` or `~user` into the
|
|
|
|
user's home directory when found at the beginning of the path.
|
|
|
|
|
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 10:54:04 +01:00
|
|
|
Include Directives
|
|
|
|
------------------
|
|
|
|
|
|
|
|
By default, the config parser does not respect include directives.
|
|
|
|
However, a caller can use the special `git_config_include` wrapper
|
|
|
|
callback to support them. To do so, you simply wrap your "real" callback
|
|
|
|
function and data pointer in a `struct config_include_data`, and pass
|
|
|
|
the wrapper to the regular config-reading functions. For example:
|
|
|
|
|
|
|
|
-------------------------------------------
|
|
|
|
int read_file_with_include(const char *file, config_fn_t fn, void *data)
|
|
|
|
{
|
|
|
|
struct config_include_data inc = CONFIG_INCLUDE_INIT;
|
|
|
|
inc.fn = fn;
|
|
|
|
inc.data = data;
|
|
|
|
return git_config_from_file(git_config_include, file, &inc);
|
|
|
|
}
|
|
|
|
-------------------------------------------
|
|
|
|
|
|
|
|
`git_config` respects includes automatically. The lower-level
|
|
|
|
`git_config_from_file` does not.
|
|
|
|
|
2014-07-28 12:10:38 +02:00
|
|
|
Custom Configsets
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
A `config_set` can be used to construct an in-memory cache for
|
|
|
|
config-like files that the caller specifies (i.e., files like `.gitmodules`,
|
|
|
|
`~/.gitconfig` etc.). For example,
|
|
|
|
|
|
|
|
---------------------------------------
|
|
|
|
struct config_set gm_config;
|
|
|
|
git_configset_init(&gm_config);
|
|
|
|
int b;
|
|
|
|
/* we add config files to the config_set */
|
|
|
|
git_configset_add_file(&gm_config, ".gitmodules");
|
|
|
|
git_configset_add_file(&gm_config, ".gitmodules_alt");
|
|
|
|
|
|
|
|
if (!git_configset_get_bool(gm_config, "submodule.frotz.ignore", &b)) {
|
|
|
|
/* hack hack hack */
|
|
|
|
}
|
|
|
|
|
|
|
|
/* when we are done with the configset */
|
|
|
|
git_configset_clear(&gm_config);
|
|
|
|
----------------------------------------
|
|
|
|
|
|
|
|
Configset API provides functions for the above mentioned work flow, including:
|
|
|
|
|
|
|
|
`void git_configset_init(struct config_set *cs)`::
|
|
|
|
|
|
|
|
Initializes the config_set `cs`.
|
|
|
|
|
|
|
|
`int git_configset_add_file(struct config_set *cs, const char *filename)`::
|
|
|
|
|
|
|
|
Parses the file and adds the variable-value pairs to the `config_set`,
|
|
|
|
dies if there is an error in parsing the file. Returns 0 on success, or
|
|
|
|
-1 if the file does not exist or is inaccessible. The user has to decide
|
|
|
|
if he wants to free the incomplete configset or continue using it when
|
|
|
|
the function returns -1.
|
|
|
|
|
|
|
|
`int git_configset_get_value(struct config_set *cs, const char *key, const char **value)`::
|
|
|
|
|
|
|
|
Finds the highest-priority value for the configuration variable `key`
|
|
|
|
and config set `cs`, stores the pointer to it in `value` and returns 0.
|
|
|
|
When the configuration variable `key` is not found, returns 1 without
|
|
|
|
touching `value`. The caller should not free or modify `value`, as it
|
|
|
|
is owned by the cache.
|
|
|
|
|
|
|
|
`const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key)`::
|
|
|
|
|
|
|
|
Finds and returns the value list, sorted in order of increasing priority
|
|
|
|
for the configuration variable `key` and config set `cs`. When the
|
|
|
|
configuration variable `key` is not found, returns NULL. The caller
|
|
|
|
should not free or modify the returned pointer, as it is owned by the cache.
|
|
|
|
|
|
|
|
`void git_configset_clear(struct config_set *cs)`::
|
|
|
|
|
|
|
|
Clears `config_set` structure, removes all saved variable-value pairs.
|
|
|
|
|
|
|
|
In addition to above functions, the `config_set` API provides type specific
|
|
|
|
functions in the vein of `git_config_get_int` and family but with an extra
|
|
|
|
parameter, pointer to struct `config_set`.
|
|
|
|
They all behave similarly to the `git_config_get*()` family described in
|
|
|
|
"Querying For Specific Variables" above.
|
|
|
|
|
2012-02-06 10:53:46 +01:00
|
|
|
Writing Config Files
|
|
|
|
--------------------
|
|
|
|
|
2014-07-28 12:42:26 +02:00
|
|
|
Git gives multiple entry points in the Config API to write config values to
|
|
|
|
files namely `git_config_set_in_file` and `git_config_set`, which write to
|
|
|
|
a specific config file or to `.git/config` respectively. They both take a
|
|
|
|
key/value pair as parameter.
|
|
|
|
In the end they both call `git_config_set_multivar_in_file` which takes four
|
|
|
|
parameters:
|
|
|
|
|
|
|
|
- the name of the file, as a string, to which key/value pairs will be written.
|
|
|
|
|
|
|
|
- the name of key, as a string. This is in canonical "flat" form: the section,
|
|
|
|
subsection, and variable segments will be separated by dots, and the section
|
|
|
|
and variable segments will be all lowercase.
|
|
|
|
E.g., `core.ignorecase`, `diff.SomeType.textconv`.
|
|
|
|
|
|
|
|
- the value of the variable, as a string. If value is equal to NULL, it will
|
|
|
|
remove the matching key from the config file.
|
|
|
|
|
|
|
|
- the value regex, as a string. It will disregard key/value pairs where value
|
|
|
|
does not match.
|
|
|
|
|
|
|
|
- a multi_replace value, as an int. If value is equal to zero, nothing or only
|
|
|
|
one matching key/value is replaced, else all matching key/values (regardless
|
|
|
|
how many) are removed, before the new pair is written.
|
|
|
|
|
|
|
|
It returns 0 on success.
|
|
|
|
|
|
|
|
Also, there are functions `git_config_rename_section` and
|
|
|
|
`git_config_rename_section_in_file` with parameters `old_name` and `new_name`
|
|
|
|
for renaming or removing sections in the config files. If NULL is passed
|
|
|
|
through `new_name` parameter, the section will be removed from the config file.
|