mirror of
https://github.com/git/git.git
synced 2024-11-01 14:57:52 +01:00
c9b5e2a57d
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>
114 lines
4.3 KiB
Text
114 lines
4.3 KiB
Text
config API
|
|
==========
|
|
|
|
The config API gives callers a way to access git configuration files
|
|
(and files which have the same syntax). See linkgit:git-config[1] for a
|
|
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
|
|
some options. It is not uncommon for the configuration to be parsed
|
|
several times during the run of a git program, with different callbacks
|
|
picking out different variables useful to themselves.
|
|
|
|
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
|
|
that git knows about, using the normal precedence rules. To do this,
|
|
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).
|
|
|
|
The `git_config_with_options` function lets the caller examine config
|
|
while adjusting some of the default behavior of `git_config`. It should
|
|
almost never be used by "regular" git code that is looking up
|
|
configuration variables. It is intended for advanced callers like
|
|
`git-config`, which are intentionally tweaking the normal config-lookup
|
|
process. It takes one extra parameter:
|
|
|
|
`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`.
|
|
|
|
There is a special version of `git_config` called `git_config_early`.
|
|
This version takes an additional parameter to specify the repository
|
|
config, instead of having it looked up via `git_path`. This is useful
|
|
early in a git program before the repository has been found. Unless
|
|
you're working with early setup code, you probably don't want to use
|
|
this.
|
|
|
|
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`.
|
|
|
|
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.
|
|
|
|
Writing Config Files
|
|
--------------------
|
|
|
|
TODO
|