4 The config API gives callers a way to access Git configuration files
5 (and files which have the same syntax). See linkgit:git-config[1] for a
6 discussion of the config file syntax.
11 Config files are parsed linearly, and each variable found is passed to a
12 caller-provided callback function. The callback function is responsible
13 for any actions to be taken on the config option, and is free to ignore
14 some options. It is not uncommon for the configuration to be parsed
15 several times during the run of a Git program, with different callbacks
16 picking out different variables useful to themselves.
18 A config callback function takes three parameters:
20 - the name of the parsed variable. This is in canonical "flat" form: the
21 section, subsection, and variable segments will be separated by dots,
22 and the section and variable segments will be all lowercase. E.g.,
23 `core.ignorecase`, `diff.SomeType.textconv`.
25 - the value of the found variable, as a string. If the variable had no
26 value specified, the value will be NULL (typically this means it
27 should be interpreted as boolean true).
29 - a void pointer passed in by the caller of the config API; this can
30 contain callback-specific data
32 A config callback should return 0 for success, or -1 if the variable
33 could not be parsed properly.
38 Most programs will simply want to look up variables in all config files
39 that Git knows about, using the normal precedence rules. To do this,
40 call `git_config` with a callback function and void data pointer.
42 `git_config` will read all config sources in order of increasing
43 priority. Thus a callback should typically overwrite previously-seen
44 entries with new ones (e.g., if both the user-wide `~/.gitconfig` and
45 repo-specific `.git/config` contain `color.ui`, the config machinery
46 will first feed the user-wide one to the callback, and then the
47 repo-specific one; by overwriting, the higher-priority repo-specific
48 value is left at the end).
50 The `git_config_with_options` function lets the caller examine config
51 while adjusting some of the default behavior of `git_config`. It should
52 almost never be used by "regular" Git code that is looking up
53 configuration variables. It is intended for advanced callers like
54 `git-config`, which are intentionally tweaking the normal config-lookup
55 process. It takes two extra parameters:
58 If this parameter is non-NULL, it specifies the name of a file to
59 parse for configuration, rather than looking in the usual files. Regular
60 `git_config` defaults to `NULL`.
63 Specify whether include directives should be followed in parsed files.
64 Regular `git_config` defaults to `1`.
66 Reading Specific Files
67 ----------------------
69 To read a specific file in git-config format, use
70 `git_config_from_file`. This takes the same callback and data parameters
73 Querying For Specific Variables
74 -------------------------------
76 For programs wanting to query for specific variables in a non-callback
77 manner, the config API provides two functions `git_config_get_value`
78 and `git_config_get_value_multi`. They both read values from an internal
79 cache generated previously from reading the config files.
81 `int git_config_get_value(const char *key, const char **value)`::
83 Finds the highest-priority value for the configuration variable `key`,
84 stores the pointer to it in `value` and returns 0. When the
85 configuration variable `key` is not found, returns 1 without touching
86 `value`. The caller should not free or modify `value`, as it is owned
89 `const struct string_list *git_config_get_value_multi(const char *key)`::
91 Finds and returns the value list, sorted in order of increasing priority
92 for the configuration variable `key`. When the configuration variable
93 `key` is not found, returns NULL. The caller should not free or modify
94 the returned pointer, as it is owned by the cache.
96 `void git_config_clear(void)`::
98 Resets and invalidates the config cache.
100 The config API also provides type specific API functions which do conversion
101 as well as retrieval for the queried variable, including:
103 `int git_config_get_int(const char *key, int *dest)`::
105 Finds and parses the value to an integer for the configuration variable
106 `key`. Dies on error; otherwise, stores the value of the parsed integer in
107 `dest` and returns 0. When the configuration variable `key` is not found,
108 returns 1 without touching `dest`.
110 `int git_config_get_ulong(const char *key, unsigned long *dest)`::
112 Similar to `git_config_get_int` but for unsigned longs.
114 `int git_config_get_bool(const char *key, int *dest)`::
116 Finds and parses the value into a boolean value, for the configuration
117 variable `key` respecting keywords like "true" and "false". Integer
118 values are converted into true/false values (when they are non-zero or
119 zero, respectively). Other values cause a die(). If parsing is successful,
120 stores the value of the parsed result in `dest` and returns 0. When the
121 configuration variable `key` is not found, returns 1 without touching
124 `int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest)`::
126 Similar to `git_config_get_bool`, except that integers are copied as-is,
127 and `is_bool` flag is unset.
129 `int git_config_get_maybe_bool(const char *key, int *dest)`::
131 Similar to `git_config_get_bool`, except that it returns -1 on error
134 `int git_config_get_string_const(const char *key, const char **dest)`::
136 Allocates and copies the retrieved string into the `dest` parameter for
137 the configuration variable `key`; if NULL string is given, prints an
138 error message and returns -1. When the configuration variable `key` is
139 not found, returns 1 without touching `dest`.
141 `int git_config_get_string(const char *key, char **dest)`::
143 Similar to `git_config_get_string_const`, except that retrieved value
144 copied into the `dest` parameter is a mutable string.
146 `int git_config_get_pathname(const char *key, const char **dest)`::
148 Similar to `git_config_get_string`, but expands `~` or `~user` into
149 the user's home directory when found at the beginning of the path.
151 `git_die_config(const char *key, const char *err, ...)`::
153 First prints the error message specified by the caller in `err` and then
154 dies printing the line number and the file name of the highest priority
155 value for the configuration variable `key`.
157 `void git_die_config_linenr(const char *key, const char *filename, int linenr)`::
159 Helper function which formats the die error message according to the
160 parameters entered. Used by `git_die_config()`. It can be used by callers
161 handling `git_config_get_value_multi()` to print the correct error message
162 for the desired value.
164 See test-config.c for usage examples.
166 Value Parsing Helpers
167 ---------------------
169 To aid in parsing string values, the config API provides callbacks with
170 a number of helper functions, including:
173 Parse the string to an integer, including unit factors. Dies on error;
174 otherwise, returns the parsed result.
177 Identical to `git_config_int`, but for unsigned longs.
180 Parse a string into a boolean value, respecting keywords like "true" and
181 "false". Integer values are converted into true/false values (when they
182 are non-zero or zero, respectively). Other values cause a die(). If
183 parsing is successful, the return value is the result.
185 `git_config_bool_or_int`::
186 Same as `git_config_bool`, except that integers are returned as-is, and
187 an `is_bool` flag is unset.
189 `git_parse_maybe_bool`::
190 Same as `git_config_bool`, except that it returns -1 on error rather
193 `git_config_string`::
194 Allocates and copies the value string into the `dest` parameter; if no
195 string is given, prints an error message and returns -1.
197 `git_config_pathname`::
198 Similar to `git_config_string`, but expands `~` or `~user` into the
199 user's home directory when found at the beginning of the path.
204 By default, the config parser does not respect include directives.
205 However, a caller can use the special `git_config_include` wrapper
206 callback to support them. To do so, you simply wrap your "real" callback
207 function and data pointer in a `struct config_include_data`, and pass
208 the wrapper to the regular config-reading functions. For example:
210 -------------------------------------------
211 int read_file_with_include(const char *file, config_fn_t fn, void *data)
213 struct config_include_data inc = CONFIG_INCLUDE_INIT;
216 return git_config_from_file(git_config_include, file, &inc);
218 -------------------------------------------
220 `git_config` respects includes automatically. The lower-level
221 `git_config_from_file` does not.
226 A `config_set` can be used to construct an in-memory cache for
227 config-like files that the caller specifies (i.e., files like `.gitmodules`,
228 `~/.gitconfig` etc.). For example,
230 ---------------------------------------
231 struct config_set gm_config;
232 git_configset_init(&gm_config);
234 /* we add config files to the config_set */
235 git_configset_add_file(&gm_config, ".gitmodules");
236 git_configset_add_file(&gm_config, ".gitmodules_alt");
238 if (!git_configset_get_bool(gm_config, "submodule.frotz.ignore", &b)) {
242 /* when we are done with the configset */
243 git_configset_clear(&gm_config);
244 ----------------------------------------
246 Configset API provides functions for the above mentioned work flow, including:
248 `void git_configset_init(struct config_set *cs)`::
250 Initializes the config_set `cs`.
252 `int git_configset_add_file(struct config_set *cs, const char *filename)`::
254 Parses the file and adds the variable-value pairs to the `config_set`,
255 dies if there is an error in parsing the file. Returns 0 on success, or
256 -1 if the file does not exist or is inaccessible. The user has to decide
257 if he wants to free the incomplete configset or continue using it when
258 the function returns -1.
260 `int git_configset_get_value(struct config_set *cs, const char *key, const char **value)`::
262 Finds the highest-priority value for the configuration variable `key`
263 and config set `cs`, stores the pointer to it in `value` and returns 0.
264 When the configuration variable `key` is not found, returns 1 without
265 touching `value`. The caller should not free or modify `value`, as it
266 is owned by the cache.
268 `const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key)`::
270 Finds and returns the value list, sorted in order of increasing priority
271 for the configuration variable `key` and config set `cs`. When the
272 configuration variable `key` is not found, returns NULL. The caller
273 should not free or modify the returned pointer, as it is owned by the cache.
275 `void git_configset_clear(struct config_set *cs)`::
277 Clears `config_set` structure, removes all saved variable-value pairs.
279 In addition to above functions, the `config_set` API provides type specific
280 functions in the vein of `git_config_get_int` and family but with an extra
281 parameter, pointer to struct `config_set`.
282 They all behave similarly to the `git_config_get*()` family described in
283 "Querying For Specific Variables" above.
288 Git gives multiple entry points in the Config API to write config values to
289 files namely `git_config_set_in_file` and `git_config_set`, which write to
290 a specific config file or to `.git/config` respectively. They both take a
291 key/value pair as parameter.
292 In the end they both call `git_config_set_multivar_in_file` which takes four
295 - the name of the file, as a string, to which key/value pairs will be written.
297 - the name of key, as a string. This is in canonical "flat" form: the section,
298 subsection, and variable segments will be separated by dots, and the section
299 and variable segments will be all lowercase.
300 E.g., `core.ignorecase`, `diff.SomeType.textconv`.
302 - the value of the variable, as a string. If value is equal to NULL, it will
303 remove the matching key from the config file.
305 - the value regex, as a string. It will disregard key/value pairs where value
308 - a multi_replace value, as an int. If value is equal to zero, nothing or only
309 one matching key/value is replaced, else all matching key/values (regardless
310 how many) are removed, before the new pair is written.
312 It returns 0 on success.
314 Also, there are functions `git_config_rename_section` and
315 `git_config_rename_section_in_file` with parameters `old_name` and `new_name`
316 for renaming or removing sections in the config files. If NULL is passed
317 through `new_name` parameter, the section will be removed from the config file.