summaryrefslogtreecommitdiff
path: root/Documentation/technical/api-config.txt
blob: 21f280ca6dbd85a1f4d1d599db1393077fc93bdf (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
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 two extra parameters:
 
`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`.
 
`respect_includes`::
Specify whether include directives should be followed in parsed files.
Regular `git_config` defaults to `1`.
 
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`.
 
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.
 
See test-config.c for usage examples.
 
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.
 
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.
 
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.
 
Writing Config Files
--------------------
 
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.