10Config🔗 i

Note that the configuration object will free the file automatically.

Further queries on this config object will access each of the config file instances in order (instances with a higher priority level will be accessed first).

The on-disk file pointed at by path will be opened and parsed; it’s expected to be a native Git config file following the default Git config syntax (see man git-config).

If the file does not exist, the file will still be added and it will be created the first time we write to it.

Note that the configuration object will free the file automatically.

Further queries on this config object will access each of the config file instances in order (instances with a higher priority level will be accessed first).

This behaviors like git_config_foreach_match except instead of all config entries it just enumerates through the given backend entry.

The user or global configuration file is usually located in $HOME/.gitconfig.

This method will try to guess the full path to that file, if the file exists. The returned path may be used on any git_config call to load the global configuration file.

This method will not guess the path to the xdg compatible config file (.config/git/config).

Look for the file in %PROGRAMDATA% used by portable git.

If /etc/gitconfig doesn’t exist, it will look for %PROGRAMFILES%.

The xdg compatible configuration file is usually located in $HOME/.config/git/config.

This method will try to guess the full path to that file, if the file exists. The returned path may be used on any git_config call to load the xdg compatible configuration file.

The callback receives the normalized name and value of each variable in the config backend, and the data pointer passed to this function. If the callback returns a non-zero value, the function stops iterating and returns that value to the caller.

The pointers passed to the callback are only valid as long as the iteration is ongoing.

This behaviors like git_config_foreach with an additional filter of a regular expression that filters which config keys are passed to the callback.

The pointers passed to the callback are only valid as long as the iteration is ongoing.

This function uses the usual C convention of 0 being false and anything else true.

All config files will be looked into, in the order of their defined level. A higher level means a higher priority. The first occurrence of the variable will be returned here.

Free the git_config_entry after use with git_config_entry_free().

git_config_get_int32(int32_t *out, const git_config *cfg, const char *name)

Get the value of an integer config variable.

All config files will be looked into, in the order of their defined level. A higher level means a higher priority. The first occurrence of the variable will be returned here.

git_config_get_int64(int64_t *out, const git_config *cfg, const char *name)

Get the value of a long integer config variable.

All config files will be looked into, in the order of their defined level. A higher level means a higher priority. The first occurrence of the variable will be returned here.

This is a helper method to easily map different possible values to a variable to integer constants that easily identify them.

A mapping array looks as follows:

git_cvar_map autocrlf_mapping[] = { {GIT_CVAR_FALSE, NULL, GIT_AUTO_CRLF_FALSE}, {GIT_CVAR_TRUE, NULL, GIT_AUTO_CRLF_TRUE}, {GIT_CVAR_STRING, "input", GIT_AUTO_CRLF_INPUT}, {GIT_CVAR_STRING, "default", GIT_AUTO_CRLF_DEFAULT}}; On any "false" value for the variable (e.g. "false", "FALSE", "no"), the mapping will store GIT_AUTO_CRLF_FALSE in the out parameter.

The same thing applies for any "true" value such as "true", "yes" or "1", storing the GIT_AUTO_CRLF_TRUE variable.

Otherwise, if the value matches the string "input" (with case insensitive comparison), the given constant will be stored in out, and likewise for "default".

If not a single match can be made to store in out, an error code will be returned.

The callback will be called on each variable found

A leading ’~’ will be expanded to the global search path (which defaults to the user’s home directory but can be overridden via git_libgit2_opts().

All config files will be looked into, in the order of their defined level. A higher level means a higher priority. The first occurrence of the variable will be returned here.

This function can only be used on snapshot config objects. The string is owned by the config and should not be freed by the user. The pointer will be valid until the config is freed.

All config files will be looked into, in the order of their defined level. A higher level means a higher priority. The first occurrence of the variable will be returned here.

The value of the config will be copied into the buffer.

All config files will be looked into, in the order of their defined level. A higher level means a higher priority. The first occurrence of the variable will be returned here.

Use git_config_next to advance the iteration and git_config_iterator_free when done.

Use git_config_next to advance the iteration and git_config_iterator_free when done.

Locking disallows anybody else from writing to that backend. Any updates made after locking will not be visible to a reader until the file is unlocked.

You can apply the changes by calling git_transaction_commit() before freeing the transaction. Either of these actions will unlock the config.

This object is empty, so you have to add a file to it before you can do anything with it.

The pointers returned by this function are valid until the iterator is freed.

Utility wrapper that finds the global, XDG and system configuration files and opens them into a single prioritized config object that can be used when accessing default config data outside a repository.

Git allows you to store your global configuration at $HOME/.config or $XDG_CONFIG_HOME/git/config. For backwards compatability, the XDG file shouldn’t be used unless the use has created it explicitly. With this function you’ll open the correct one to write to.

The returned config object can be used to perform get/set/delete operations on a single specific level.

Getting several times the same level from the same parent multi-level config will return different config instances, but containing the same config_file instance.

This method is a simple utility wrapper for the following sequence of calls: - git_config_new - git_config_add_file_ondisk

Valid values for true are: ’true’, ’yes’, ’on’, 1 or any number different from 0 Valid values for false are: ’false’, ’no’, ’off’, 0

git_config_parse_int32(int32_t *out, const char *value)

Parse a string value as an int32.

An optional value suffix of ’k’, ’m’, or ’g’ will cause the value to be multiplied by 1024, 1048576, or 1073741824 prior to output.

git_config_parse_int64(int64_t *out, const char *value)

Parse a string value as an int64.

An optional value suffix of ’k’, ’m’, or ’g’ will cause the value to be multiplied by 1024, 1048576, or 1073741824 prior to output.

A leading ’~’ will be expanded to the global search path (which defaults to the user’s home directory but can be overridden via git_libgit2_opts().

If the value does not begin with a tilde, the input will be returned.

git_config_set_int32(git_config *cfg, const char *name, int32_t value)

Set the value of an integer config variable in the config file with the highest level (usually the local one).

git_config_set_int64(git_config *cfg, const char *name, int64_t value)

Set the value of a long integer config variable in the config file with the highest level (usually the local one).

A copy of the string is made and the user is free to use it afterwards.

Create a snapshot of the current state of a configuration, which allows you to look into a consistent view of the configuration for looking up complex values (e.g. a remote, submodule).

The string returned when querying such a config object is valid until it is freed.