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); }
The config API gives callers a way to access Git configuration files (and files which have the same syntax). See git-config(1) for a discussion of the config file syntax.
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.
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:
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.
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.
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.
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.
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.
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.
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:
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.
Similar to git_config_get_int but for unsigned longs.
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.
Similar to git_config_get_bool, except that integers are copied as-is, and is_bool flag is unset.
Similar to git_config_get_bool, except that it returns -1 on error rather than dying.
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.
Similar to git_config_get_string_const, except that retrieved value copied into the dest parameter is a mutable string.
Similar to git_config_get_string, but expands ~ or ~user into the user’s home directory when found at the beginning of the path.
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.
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.
See test-config.c for usage examples.
To aid in parsing string values, the config API provides callbacks with a number of helper functions, including:
Parse the string to an integer, including unit factors. Dies on error; otherwise, returns the parsed result.
Identical to git_config_int, but for unsigned longs.
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.
Same as git_config_bool, except that integers are returned as-is, and an is_bool flag is unset.
Same as git_config_bool, except that it returns -1 on error rather than dying.
Allocates and copies the value string into the dest parameter; if no string is given, prints an error message and returns -1.
Similar to git_config_string, but expands ~ or ~user into the user’s home directory when found at the beginning of the path.
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.
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:
Initializes the config_set cs.
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.
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.
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.
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.
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.