2017-06-14 18:07:34 +00:00
|
|
|
#ifndef CONFIG_H
|
|
|
|
#define CONFIG_H
|
|
|
|
|
2018-08-15 17:54:05 +00:00
|
|
|
#include "hashmap.h"
|
|
|
|
#include "string-list.h"
|
config: pass 'repo' directly to 'config_with_options()'
Add a 'struct repository' argument to 'config_with_options()' and remove the
'repo' field from 'struct git_config_source'.
A 'struct repository' instance was originally added to the config source in
e3e8bf046e9 (submodule-config: pass repo upon blob config read, 2021-08-16)
to improve how submodule blob config content was accessed. At the time, this
was the only use for a 'repository' instance, so it was naturally added only
where it was needed: to 'struct git_config_source'. However, in upcoming
patches, 'config_with_options()' will need the repository instance to access
extension information (regardless of whether a 'config_source' exists). To
make the 'struct repository' instance more easily accessible, move it into
the function's arguments.
Update all callers of 'config_with_options()' to pass the appropriate 'repo'
value:
* in 'builtin/config.c', use 'the_repository'
* in 'submodule--config.c', use the 'repo' arg in 'config_from_gitmodules()'
* in 'read_[very_]early_config()' & 'read_protected_config()', set 'repo' to
NULL (repository instances aren't available there)
* in 'populate_remote_urls()', use the repo instance that has been added to
the 'struct config_include_data'
* in 'repo_read_config()', use the given 'repo' arg
Finally, note that this patch eliminates the fallback to 'the_repository'
that previously existed for the 'config_source' repo instance if it was
NULL. The fallback is no longer necessary, as the 'repo' is set explicitly
in all cases where it is needed.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-26 01:32:59 +00:00
|
|
|
#include "repository.h"
|
2023-09-29 21:20:51 +00:00
|
|
|
#include "parse.h"
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* The config API gives callers a way to access Git configuration files
|
|
|
|
* (and files which have the same 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.
|
|
|
|
*/
|
|
|
|
|
2018-08-15 17:54:05 +00:00
|
|
|
struct object_id;
|
|
|
|
|
2017-06-14 18:07:34 +00:00
|
|
|
/* git_config_parse_key() returns these negated: */
|
|
|
|
#define CONFIG_INVALID_KEY 1
|
|
|
|
#define CONFIG_NO_SECTION_OR_NAME 2
|
|
|
|
/* git_config_set_gently(), git_config_set_multivar_gently() return the above or these: */
|
|
|
|
#define CONFIG_NO_LOCK -1
|
|
|
|
#define CONFIG_INVALID_FILE 3
|
|
|
|
#define CONFIG_NO_WRITE 4
|
|
|
|
#define CONFIG_NOTHING_SET 5
|
|
|
|
#define CONFIG_INVALID_PATTERN 6
|
|
|
|
#define CONFIG_GENERIC_ERROR 7
|
|
|
|
|
|
|
|
#define CONFIG_REGEX_NONE ((void *)1)
|
|
|
|
|
2020-02-10 00:30:57 +00:00
|
|
|
enum config_scope {
|
|
|
|
CONFIG_SCOPE_UNKNOWN = 0,
|
|
|
|
CONFIG_SCOPE_SYSTEM,
|
|
|
|
CONFIG_SCOPE_GLOBAL,
|
|
|
|
CONFIG_SCOPE_LOCAL,
|
|
|
|
CONFIG_SCOPE_WORKTREE,
|
|
|
|
CONFIG_SCOPE_COMMAND,
|
2020-02-10 00:30:58 +00:00
|
|
|
CONFIG_SCOPE_SUBMODULE,
|
2020-02-10 00:30:57 +00:00
|
|
|
};
|
|
|
|
const char *config_scope_name(enum config_scope scope);
|
|
|
|
|
2017-06-14 18:07:34 +00:00
|
|
|
struct git_config_source {
|
|
|
|
unsigned int use_stdin:1;
|
|
|
|
const char *file;
|
|
|
|
const char *blob;
|
2020-02-10 00:30:57 +00:00
|
|
|
enum config_scope scope;
|
2017-06-14 18:07:34 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
enum config_origin_type {
|
config: report cached filenames in die_bad_number()
If, when parsing numbers from config, die_bad_number() is called, it
reports the filename and config source type if we were parsing a config
file, but not if we were iterating a config_set (it defaults to a less
specific error message). Most call sites don't parse config files
because config is typically read once and cached, so we only report
filename and config source type in "git config --type" (since "git
config" always parses config files).
This could have been fixed when we taught the current_config_*
functions to respect config_set values (0d44a2dacc (config: return
configset value for current_config_ functions, 2016-05-26), but it was
hard to spot then and we might have just missed it (I didn't find
mention of die_bad_number() in the original ML discussion [1].)
Fix this by refactoring the current_config_* functions into variants
that don't BUG() when we aren't reading config, and using the resulting
functions in die_bad_number(). "git config --get[-regexp] --type=int"
cannot use the non-refactored version because it parses the int value
_after_ parsing the config file, which would run into the BUG().
Since the refactored functions aren't public, they use "struct
config_reader".
1. https://lore.kernel.org/git/20160518223712.GA18317@sigill.intra.peff.net/
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 17:51:53 +00:00
|
|
|
CONFIG_ORIGIN_UNKNOWN = 0,
|
2017-06-14 18:07:34 +00:00
|
|
|
CONFIG_ORIGIN_BLOB,
|
|
|
|
CONFIG_ORIGIN_FILE,
|
|
|
|
CONFIG_ORIGIN_STDIN,
|
|
|
|
CONFIG_ORIGIN_SUBMODULE_BLOB,
|
|
|
|
CONFIG_ORIGIN_CMDLINE
|
|
|
|
};
|
|
|
|
|
2018-04-09 08:32:05 +00:00
|
|
|
enum config_event_t {
|
|
|
|
CONFIG_EVENT_SECTION,
|
|
|
|
CONFIG_EVENT_ENTRY,
|
|
|
|
CONFIG_EVENT_WHITESPACE,
|
|
|
|
CONFIG_EVENT_COMMENT,
|
|
|
|
CONFIG_EVENT_EOF,
|
|
|
|
CONFIG_EVENT_ERROR
|
|
|
|
};
|
|
|
|
|
2023-06-28 19:26:30 +00:00
|
|
|
struct config_source;
|
2018-04-09 08:32:05 +00:00
|
|
|
/*
|
|
|
|
* The parser event function (if not NULL) is called with the event type and
|
|
|
|
* the begin/end offsets of the parsed elements.
|
|
|
|
*
|
|
|
|
* Note: for CONFIG_EVENT_ENTRY (i.e. config variables), the trailing newline
|
|
|
|
* character is considered part of the element.
|
|
|
|
*/
|
|
|
|
typedef int (*config_parser_event_fn_t)(enum config_event_t type,
|
|
|
|
size_t begin_offset, size_t end_offset,
|
2023-06-28 19:26:30 +00:00
|
|
|
struct config_source *cs,
|
2018-04-09 08:32:05 +00:00
|
|
|
void *event_fn_data);
|
|
|
|
|
2017-06-14 18:07:34 +00:00
|
|
|
struct config_options {
|
|
|
|
unsigned int respect_includes : 1;
|
2019-04-15 20:39:46 +00:00
|
|
|
unsigned int ignore_repo : 1;
|
|
|
|
unsigned int ignore_worktree : 1;
|
|
|
|
unsigned int ignore_cmdline : 1;
|
2019-04-29 20:14:22 +00:00
|
|
|
unsigned int system_gently : 1;
|
2022-01-18 17:47:40 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For internal use. Include all includeif.hasremoteurl paths without
|
|
|
|
* checking if the repo has that remote URL, and when doing so, verify
|
|
|
|
* that files included in this way do not configure any remote URLs
|
|
|
|
* themselves.
|
|
|
|
*/
|
|
|
|
unsigned int unconditional_remote_url : 1;
|
|
|
|
|
2017-06-14 18:07:38 +00:00
|
|
|
const char *commondir;
|
2017-06-14 18:07:34 +00:00
|
|
|
const char *git_dir;
|
2023-06-28 19:26:30 +00:00
|
|
|
/*
|
|
|
|
* event_fn and event_fn_data are for internal use only. Handles events
|
|
|
|
* emitted by the config parser.
|
|
|
|
*/
|
2018-04-09 08:32:05 +00:00
|
|
|
config_parser_event_fn_t event_fn;
|
|
|
|
void *event_fn_data;
|
2018-06-28 22:05:00 +00:00
|
|
|
enum config_error_action {
|
|
|
|
CONFIG_ERROR_UNSET = 0, /* use source-specific default */
|
|
|
|
CONFIG_ERROR_DIE, /* die() on error */
|
|
|
|
CONFIG_ERROR_ERROR, /* error() on error, return -1 */
|
2018-06-28 22:05:09 +00:00
|
|
|
CONFIG_ERROR_SILENT, /* return -1 */
|
2018-06-28 22:05:00 +00:00
|
|
|
} error_action;
|
2017-06-14 18:07:34 +00:00
|
|
|
};
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
/* Config source metadata for a given config key-value pair */
|
|
|
|
struct key_value_info {
|
|
|
|
const char *filename;
|
|
|
|
int linenr;
|
|
|
|
enum config_origin_type origin_type;
|
|
|
|
enum config_scope scope;
|
2023-06-28 19:26:29 +00:00
|
|
|
const char *path;
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
};
|
|
|
|
#define KVI_INIT { \
|
|
|
|
.filename = NULL, \
|
|
|
|
.linenr = -1, \
|
|
|
|
.origin_type = CONFIG_ORIGIN_UNKNOWN, \
|
|
|
|
.scope = CONFIG_SCOPE_UNKNOWN, \
|
2023-06-28 19:26:29 +00:00
|
|
|
.path = NULL, \
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Captures additional information that a config callback can use. */
|
|
|
|
struct config_context {
|
|
|
|
/* Config source metadata for key and value. */
|
|
|
|
const struct key_value_info *kvi;
|
|
|
|
};
|
|
|
|
#define CONFIG_CONTEXT_INIT { 0 }
|
|
|
|
|
2019-10-23 05:30:52 +00:00
|
|
|
/**
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
* A config callback function takes four parameters:
|
2019-10-23 05:30:52 +00:00
|
|
|
*
|
|
|
|
* - 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).
|
|
|
|
*
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
* - the 'config context', that is, additional information about the config
|
|
|
|
* iteration operation provided by the config machinery. For example, this
|
|
|
|
* includes information about the config source being parsed (e.g. the
|
|
|
|
* filename).
|
|
|
|
*
|
2019-10-23 05:30:52 +00:00
|
|
|
* - 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.
|
|
|
|
*/
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
typedef int (*config_fn_t)(const char *, const char *,
|
|
|
|
const struct config_context *, void *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
int git_default_config(const char *, const char *,
|
|
|
|
const struct config_context *, void *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Read a specific file in git-config format.
|
|
|
|
* This function takes the same callback and data parameters as `git_config`.
|
2022-01-18 17:47:39 +00:00
|
|
|
*
|
|
|
|
* Unlike git_config(), this function does not respect includes.
|
2019-10-23 05:30:52 +00:00
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_from_file(config_fn_t fn, const char *, void *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_from_file_with_options(config_fn_t fn, const char *,
|
2023-06-28 19:26:24 +00:00
|
|
|
void *, enum config_scope,
|
2019-04-29 08:28:23 +00:00
|
|
|
const struct config_options *);
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_from_mem(config_fn_t fn,
|
2019-04-29 08:28:23 +00:00
|
|
|
const enum config_origin_type,
|
|
|
|
const char *name,
|
|
|
|
const char *buf, size_t len,
|
2023-06-28 19:26:24 +00:00
|
|
|
void *data, enum config_scope scope,
|
|
|
|
const struct config_options *opts);
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_from_blob_oid(config_fn_t fn, const char *name,
|
2021-08-16 21:09:57 +00:00
|
|
|
struct repository *repo,
|
2023-06-28 19:26:24 +00:00
|
|
|
const struct object_id *oid, void *data,
|
|
|
|
enum config_scope scope);
|
2019-04-29 08:28:14 +00:00
|
|
|
void git_config_push_parameter(const char *text);
|
2021-01-12 12:26:45 +00:00
|
|
|
void git_config_push_env(const char *spec);
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_from_parameters(config_fn_t fn, void *data);
|
|
|
|
void read_early_config(config_fn_t cb, void *data);
|
2019-05-13 14:50:32 +00:00
|
|
|
void read_very_early_config(config_fn_t cb, void *data);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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).
|
2022-01-18 17:47:39 +00:00
|
|
|
*
|
|
|
|
* Unlike git_config_from_file(), this function respects includes.
|
2019-10-23 05:30:52 +00:00
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
void git_config(config_fn_t fn, void *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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:
|
|
|
|
*
|
|
|
|
* - `config_source`
|
|
|
|
* If this parameter is non-NULL, it specifies the source to parse for
|
|
|
|
* configuration, rather than looking in the usual files. See `struct
|
|
|
|
* git_config_source` in `config.h` for details. Regular `git_config` defaults
|
|
|
|
* to `NULL`.
|
|
|
|
*
|
|
|
|
* - `opts`
|
|
|
|
* Specify options to adjust the behavior of parsing config files. See `struct
|
|
|
|
* config_options` in `config.h` for details. As an example: regular `git_config`
|
|
|
|
* sets `opts.respect_includes` to `1` by default.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int config_with_options(config_fn_t fn, void *,
|
2019-04-29 08:28:23 +00:00
|
|
|
struct git_config_source *config_source,
|
config: pass 'repo' directly to 'config_with_options()'
Add a 'struct repository' argument to 'config_with_options()' and remove the
'repo' field from 'struct git_config_source'.
A 'struct repository' instance was originally added to the config source in
e3e8bf046e9 (submodule-config: pass repo upon blob config read, 2021-08-16)
to improve how submodule blob config content was accessed. At the time, this
was the only use for a 'repository' instance, so it was naturally added only
where it was needed: to 'struct git_config_source'. However, in upcoming
patches, 'config_with_options()' will need the repository instance to access
extension information (regardless of whether a 'config_source' exists). To
make the 'struct repository' instance more easily accessible, move it into
the function's arguments.
Update all callers of 'config_with_options()' to pass the appropriate 'repo'
value:
* in 'builtin/config.c', use 'the_repository'
* in 'submodule--config.c', use the 'repo' arg in 'config_from_gitmodules()'
* in 'read_[very_]early_config()' & 'read_protected_config()', set 'repo' to
NULL (repository instances aren't available there)
* in 'populate_remote_urls()', use the repo instance that has been added to
the 'struct config_include_data'
* in 'repo_read_config()', use the given 'repo' arg
Finally, note that this patch eliminates the fallback to 'the_repository'
that previously existed for the 'config_source' repo instance if it was
NULL. The fallback is no longer necessary, as the 'repo' is set explicitly
in all cases where it is needed.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-26 01:32:59 +00:00
|
|
|
struct repository *repo,
|
2019-04-29 08:28:23 +00:00
|
|
|
const struct config_options *opts);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Value Parsing Helpers
|
|
|
|
* ---------------------
|
|
|
|
*
|
|
|
|
* The following helper functions aid in parsing string values
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Parse the string to an integer, including unit factors. Dies on error;
|
|
|
|
* otherwise, returns the parsed result.
|
|
|
|
*/
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
int git_config_int(const char *, const char *, const struct key_value_info *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
int64_t git_config_int64(const char *, const char *,
|
|
|
|
const struct key_value_info *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Identical to `git_config_int`, but for unsigned longs.
|
|
|
|
*/
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
unsigned long git_config_ulong(const char *, const char *,
|
|
|
|
const struct key_value_info *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
ssize_t git_config_ssize_t(const char *, const char *,
|
|
|
|
const struct key_value_info *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Same as `git_config_bool`, except that integers are returned as-is, and
|
|
|
|
* an `is_bool` flag is unset.
|
|
|
|
*/
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
int git_config_bool_or_int(const char *, const char *,
|
|
|
|
const struct key_value_info *, int *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_bool(const char *, const char *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Allocates and copies the value string into the `dest` parameter; if no
|
|
|
|
* string is given, prints an error message and returns -1.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_string(const char **, const char *, const char *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Similar to `git_config_string`, but expands `~` or `~user` into the
|
|
|
|
* user's home directory when found at the beginning of the path.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_pathname(const char **, const char *, const char *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_expiry_date(timestamp_t *, const char *, const char *);
|
|
|
|
int git_config_color(char *, const char *, const char *);
|
|
|
|
int git_config_set_in_file_gently(const char *, const char *, const char *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* write config values to a specific config file, takes a key/value pair as
|
|
|
|
* parameter.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
void git_config_set_in_file(const char *, const char *, const char *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_set_gently(const char *, const char *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
2022-02-07 21:33:00 +00:00
|
|
|
/**
|
|
|
|
* Write a config value that should apply to the current worktree. If
|
|
|
|
* extensions.worktreeConfig is enabled, then the write will happen in the
|
|
|
|
* current worktree's config. Otherwise, write to the common config file.
|
|
|
|
*/
|
|
|
|
int repo_config_set_worktree_gently(struct repository *, const char *, const char *);
|
|
|
|
|
2019-10-23 05:30:52 +00:00
|
|
|
/**
|
|
|
|
* write config values to `.git/config`, takes a key/value pair as parameter.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
void git_config_set(const char *, const char *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
2020-04-10 19:46:07 +00:00
|
|
|
int git_config_parse_key(const char *, char **, size_t *);
|
2020-11-25 22:12:49 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The following macros specify flag bits that alter the behavior
|
|
|
|
* of the git_config_set_multivar*() methods.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When CONFIG_FLAGS_MULTI_REPLACE is specified, all matching key/values
|
|
|
|
* are removed before a single new pair is written. If the flag is not
|
|
|
|
* present, then set operations replace only the first match.
|
|
|
|
*/
|
|
|
|
#define CONFIG_FLAGS_MULTI_REPLACE (1 << 0)
|
|
|
|
|
2020-11-25 22:12:54 +00:00
|
|
|
/*
|
|
|
|
* When CONFIG_FLAGS_FIXED_VALUE is specified, match key/value pairs
|
|
|
|
* by string comparison (not regex match) to the provided value_pattern
|
|
|
|
* parameter.
|
|
|
|
*/
|
|
|
|
#define CONFIG_FLAGS_FIXED_VALUE (1 << 1)
|
|
|
|
|
2020-11-25 22:12:49 +00:00
|
|
|
int git_config_set_multivar_gently(const char *, const char *, const char *, unsigned);
|
|
|
|
void git_config_set_multivar(const char *, const char *, const char *, unsigned);
|
2022-02-07 21:33:00 +00:00
|
|
|
int repo_config_set_multivar_gently(struct repository *, const char *, const char *, const char *, unsigned);
|
2020-11-25 22:12:49 +00:00
|
|
|
int git_config_set_multivar_in_file_gently(const char *, const char *, const char *, const char *, unsigned);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*
|
2020-11-25 22:12:49 +00:00
|
|
|
* - a flags value with bits corresponding to the CONFIG_FLAG_* macros.
|
2019-10-23 05:30:52 +00:00
|
|
|
*
|
|
|
|
* It returns 0 on success.
|
|
|
|
*/
|
2020-11-25 22:12:49 +00:00
|
|
|
void git_config_set_multivar_in_file(const char *config_filename,
|
|
|
|
const char *key,
|
|
|
|
const char *value,
|
2020-11-25 22:12:50 +00:00
|
|
|
const char *value_pattern,
|
2020-11-25 22:12:49 +00:00
|
|
|
unsigned flags);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* rename or remove sections in the config file
|
|
|
|
* parameters `old_name` and `new_name`
|
|
|
|
* If NULL is passed through `new_name` parameter,
|
|
|
|
* the section will be removed from the config file.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_rename_section(const char *, const char *);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_rename_section_in_file(const char *, const char *, const char *);
|
|
|
|
int git_config_copy_section(const char *, const char *);
|
|
|
|
int git_config_copy_section_in_file(const char *, const char *, const char *);
|
|
|
|
int git_config_system(void);
|
|
|
|
int config_error_nonbool(const char *);
|
2017-06-14 18:07:34 +00:00
|
|
|
#if defined(__GNUC__)
|
|
|
|
#define config_error_nonbool(s) (config_error_nonbool(s), const_error())
|
|
|
|
#endif
|
|
|
|
|
2021-04-19 12:31:08 +00:00
|
|
|
char *git_system_config(void);
|
2021-04-19 12:31:12 +00:00
|
|
|
void git_global_config(char **user, char **xdg);
|
2021-04-19 12:31:08 +00:00
|
|
|
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_parse_parameter(const char *, config_fn_t fn, void *data);
|
2017-06-14 18:07:34 +00:00
|
|
|
|
2023-06-28 19:26:23 +00:00
|
|
|
const char *config_origin_type_name(enum config_origin_type type);
|
config.c: pass ctx with CLI config
Pass config_context when parsing CLI config. To provide the .kvi member,
refactor out kvi_from_param() from the logic that caches CLI config in
configsets. Now that config_context and config_context.kvi is always
present when config machinery calls config callbacks, plumb "kvi" so
that we can remove all calls of current_config_scope() except for
trace2/*.c (which will be handled in a later commit), and remove all
other current_config_*() (the functions themselves and their calls).
Note that this results in .kvi containing a different, more complete
set of information than the mocked up "struct config_source" in
git_config_from_parameters().
Plumbing "kvi" reveals a few places where we've been doing the wrong
thing:
* git_config_parse_parameter() hasn't been setting config source
information, so plumb "kvi" there too.
* Several sites in builtin/config.c have been calling current_config_*()
functions outside of config callbacks (indirectly, via the
format_config() helper), which means they're reading state that isn't
set correctly:
* "git config --get-urlmatch --show-scope" iterates config to collect
values, but then attempts to display the scope after config
iteration, causing the "unknown" scope to be shown instead of the
config file's scope. It's clear that this wasn't intended: we knew
that "--get-urlmatch" couldn't show config source metadata, which is
why "--show-origin" was marked incompatible with "--get-urlmatch"
when it was introduced [1]. It was most likely a mistake that we
allowed "--show-scope" to sneak through.
Fix this by copying the "kvi" value in the collection phase so that
it can be read back later. This means that we can now support "git
config --get-urlmatch --show-origin", but that is left unchanged
for now.
* "git config --default" doesn't have config source metadata when
displaying the default value, so "--show-scope" also results in
"unknown", and "--show-origin" results in a BUG(). Fix this by
treating the default value as if it came from the command line (e.g.
like we do with "git -c" or "git config --file"), using
kvi_from_param().
[1] https://lore.kernel.org/git/20160205112001.GA13397@sigill.intra.peff.net/
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:25 +00:00
|
|
|
void kvi_from_param(struct key_value_info *out);
|
2017-06-14 18:07:34 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Match and parse a config key of the form:
|
|
|
|
*
|
|
|
|
* section.(subsection.)?key
|
|
|
|
*
|
|
|
|
* (i.e., what gets handed to a config_fn_t). The caller provides the section;
|
|
|
|
* we return -1 if it does not match, 0 otherwise. The subsection and key
|
|
|
|
* out-parameters are filled by the function (and *subsection is NULL if it is
|
|
|
|
* missing).
|
|
|
|
*
|
|
|
|
* If the subsection pointer-to-pointer passed in is NULL, returns 0 only if
|
|
|
|
* there is no subsection at all.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int parse_config_key(const char *var,
|
2019-04-29 08:28:23 +00:00
|
|
|
const char *section,
|
2020-04-10 19:44:28 +00:00
|
|
|
const char **subsection, size_t *subsection_len,
|
2019-04-29 08:28:23 +00:00
|
|
|
const char **key);
|
2017-06-14 18:07:34 +00:00
|
|
|
|
2019-10-23 05:30:52 +00:00
|
|
|
/**
|
|
|
|
* 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
|
|
|
|
*/
|
|
|
|
|
2017-06-14 18:07:34 +00:00
|
|
|
struct config_set_element {
|
|
|
|
struct hashmap_entry ent;
|
|
|
|
char *key;
|
|
|
|
struct string_list value_list;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct configset_list_item {
|
|
|
|
struct config_set_element *e;
|
|
|
|
int value_index;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* the contents of the list are ordered according to their
|
|
|
|
* position in the config files and order of parsing the files.
|
|
|
|
* (i.e. key-value pair at the last position of .git/config will
|
|
|
|
* be at the last item of the list)
|
|
|
|
*/
|
|
|
|
struct configset_list {
|
|
|
|
struct configset_list_item *items;
|
|
|
|
unsigned int nr, alloc;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct config_set {
|
|
|
|
struct hashmap config_hash;
|
|
|
|
int hash_initialized;
|
|
|
|
struct configset_list list;
|
|
|
|
};
|
|
|
|
|
2019-10-23 05:30:52 +00:00
|
|
|
/**
|
|
|
|
* Initializes the config_set `cs`.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
void git_configset_init(struct config_set *cs);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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
|
2021-06-15 14:11:10 +00:00
|
|
|
* -1 if the file does not exist or is inaccessible. The caller decides
|
|
|
|
* whether to free the incomplete configset or continue using it when
|
2019-10-23 05:30:52 +00:00
|
|
|
* the function returns -1.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_configset_add_file(struct config_set *cs, const char *filename);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Finds and returns the value list, sorted in order of increasing priority
|
|
|
|
* for the configuration variable `key` and config set `cs`. When the
|
2023-03-28 14:04:24 +00:00
|
|
|
* configuration variable `key` is not found, returns 1 without touching
|
|
|
|
* `value`.
|
|
|
|
*
|
|
|
|
* The key will be parsed for validity with git_config_parse_key(), on
|
|
|
|
* error a negative value will be returned.
|
|
|
|
*
|
|
|
|
* The caller should not free or modify the returned pointer, as it is
|
|
|
|
* owned by the cache.
|
2019-10-23 05:30:52 +00:00
|
|
|
*/
|
2023-03-28 14:04:24 +00:00
|
|
|
RESULT_MUST_BE_USED
|
|
|
|
int git_configset_get_value_multi(struct config_set *cs, const char *key,
|
|
|
|
const struct string_list **dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
config API: add "string" version of *_value_multi(), fix segfaults
Fix numerous and mostly long-standing segfaults in consumers of
the *_config_*value_multi() API. As discussed in the preceding commit
an empty key in the config syntax yields a "NULL" string, which these
users would give to strcmp() (or similar), resulting in segfaults.
As this change shows, most users users of the *_config_*value_multi()
API didn't really want such an an unsafe and low-level API, let's give
them something with the safety of git_config_get_string() instead.
This fix is similar to what the *_string() functions and others
acquired in[1] and [2]. Namely introducing and using a safer
"*_get_string_multi()" variant of the low-level "_*value_multi()"
function.
This fixes segfaults in code introduced in:
- d811c8e17c6 (versionsort: support reorder prerelease suffixes, 2015-02-26)
- c026557a373 (versioncmp: generalize version sort suffix reordering, 2016-12-08)
- a086f921a72 (submodule: decouple url and submodule interest, 2017-03-17)
- a6be5e6764a (log: add log.excludeDecoration config option, 2020-04-16)
- 92156291ca8 (log: add default decoration filter, 2022-08-05)
- 50a044f1e40 (gc: replace config subprocesses with API calls, 2022-09-27)
There are now two users ofthe low-level API:
- One in "builtin/for-each-repo.c", which we'll convert in a
subsequent commit.
- The "t/helper/test-config.c" code added in [3].
As seen in the preceding commit we need to give the
"t/helper/test-config.c" caller these "NULL" entries.
We could also alter the underlying git_configset_get_value_multi()
function to be "string safe", but doing so would leave no room for
other variants of "*_get_value_multi()" that coerce to other types.
Such coercion can't be built on the string version, since as we've
established "NULL" is a true value in the boolean context, but if we
coerced it to "" for use in a list of strings it'll be subsequently
coerced to "false" as a boolean.
The callback pattern being used here will make it easy to introduce
e.g. a "multi" variant which coerces its values to "bool", "int",
"path" etc.
1. 40ea4ed9032 (Add config_error_nonbool() helper function,
2008-02-11)
2. 6c47d0e8f39 (config.c: guard config parser from value=NULL,
2008-02-11).
3. 4c715ebb96a (test-config: add tests for the config_set API,
2014-07-28)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 14:04:27 +00:00
|
|
|
/**
|
|
|
|
* A validation wrapper for git_configset_get_value_multi() which does
|
|
|
|
* for it what git_configset_get_string() does for
|
|
|
|
* git_configset_get_value().
|
|
|
|
*
|
|
|
|
* The configuration syntax allows for "[section] key", which will
|
|
|
|
* give us a NULL entry in the "struct string_list", as opposed to
|
|
|
|
* "[section] key =" which is the empty string. Most users of the API
|
|
|
|
* are not prepared to handle NULL in a "struct string_list".
|
|
|
|
*/
|
|
|
|
int git_configset_get_string_multi(struct config_set *cs, const char *key,
|
|
|
|
const struct string_list **dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Clears `config_set` structure, removes all saved variable-value pairs.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
void git_configset_clear(struct config_set *cs);
|
2018-08-06 14:33:12 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* These functions return 1 if not found, and 0 if found, leaving the found
|
|
|
|
* value in the 'dest' pointer.
|
|
|
|
*/
|
2019-10-23 05:30:52 +00:00
|
|
|
|
config API: add and use a "git_config_get()" family of functions
We already have the basic "git_config_get_value()" function and its
"repo_*" and "configset" siblings to get a given "key" and assign the
last key found to a provided "value".
But some callers don't care about that value, but just want to use the
return value of the "get_value()" function to check whether the key
exist (or another non-zero return value).
The immediate motivation for this is that a subsequent commit will
need to change all callers of the "*_get_value_multi()" family of
functions. In two cases here we (ab)used it to check whether we had
any values for the given key, but didn't care about the return value.
The rest of the callers here used various other config API functions
to do the same, all of which resolved to the same underlying functions
to provide the answer.
Some of these were using either git_config_get_string() or
git_config_get_string_tmp(), see fe4c750fb13 (submodule--helper: fix a
configure_added_submodule() leak, 2022-09-01) for a recent example. We
can now use a helper function that doesn't require a throwaway
variable.
We could have changed git_configset_get_value_multi() (and then
git_config_get_value() etc.) to accept a "NULL" as a "dest" for all
callers, but let's avoid changing the behavior of existing API
users. Having an "unused" value that we throw away internal to
config.c is cheap.
A "NULL as optional dest" pattern is also more fragile, as the intent
of the caller might be misinterpreted if he were to accidentally pass
"NULL", e.g. when "dest" is passed in from another function.
Another name for this function could have been
"*_config_key_exists()", as suggested in [1]. That would work for all
of these callers, and would currently be equivalent to this function,
as the git_configset_get_value() API normalizes all non-zero return
values to a "1".
But adding that API would set us up to lose information, as e.g. if
git_config_parse_key() in the underlying configset_find_element()
fails we'd like to return -1, not 1.
Let's change the underlying configset_find_element() function to
support this use-case, we'll make further use of it in a subsequent
commit where the git_configset_get_value_multi() function itself will
expose this new return value.
This still leaves various inconsistencies and clobbering or ignoring
of the return value in place. E.g here we're modifying
configset_add_value(), but ever since it was added in [2] we've been
ignoring its "int" return value, but as we're changing the
configset_find_element() it uses, let's have it faithfully ferry that
"ret" along.
Let's also use the "RESULT_MUST_BE_USED" macro introduced in [3] to
assert that we're checking the return value of
configset_find_element().
We're leaving the same change to configset_add_value() for some future
series. Once we start paying attention to its return value we'd need
to ferry it up as deep as do_config_from(), and would need to make
least read_{,very_}early_config() and git_protected_config() return an
"int" instead of "void". Let's leave that for now, and focus on
the *_get_*() functions.
1. 3c8687a73ee (add `config_set` API for caching config-like files, 2014-07-28)
2. https://lore.kernel.org/git/xmqqczadkq9f.fsf@gitster.g/
3. 1e8697b5c4e (submodule--helper: check repo{_submodule,}_init()
return values, 2022-09-01),
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 14:04:22 +00:00
|
|
|
/**
|
|
|
|
* git_configset_get() returns negative values on error, see
|
|
|
|
* repo_config_get() below.
|
|
|
|
*/
|
|
|
|
RESULT_MUST_BE_USED
|
|
|
|
int git_configset_get(struct config_set *cs, const char *key);
|
|
|
|
|
2019-10-23 05:30:52 +00:00
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:27 +00:00
|
|
|
int git_configset_get_value(struct config_set *cs, const char *key,
|
|
|
|
const char **dest, struct key_value_info *kvi);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_configset_get_string(struct config_set *cs, const char *key, char **dest);
|
|
|
|
int git_configset_get_int(struct config_set *cs, const char *key, int *dest);
|
|
|
|
int git_configset_get_ulong(struct config_set *cs, const char *key, unsigned long *dest);
|
|
|
|
int git_configset_get_bool(struct config_set *cs, const char *key, int *dest);
|
|
|
|
int git_configset_get_bool_or_int(struct config_set *cs, const char *key, int *is_bool, int *dest);
|
|
|
|
int git_configset_get_maybe_bool(struct config_set *cs, const char *key, int *dest);
|
|
|
|
int git_configset_get_pathname(struct config_set *cs, const char *key, const char **dest);
|
2017-06-14 18:07:34 +00:00
|
|
|
|
2017-06-22 18:43:42 +00:00
|
|
|
/* Functions for reading a repository's config */
|
|
|
|
struct repository;
|
2019-04-29 08:28:14 +00:00
|
|
|
void repo_config(struct repository *repo, config_fn_t fn, void *data);
|
config API: add and use a "git_config_get()" family of functions
We already have the basic "git_config_get_value()" function and its
"repo_*" and "configset" siblings to get a given "key" and assign the
last key found to a provided "value".
But some callers don't care about that value, but just want to use the
return value of the "get_value()" function to check whether the key
exist (or another non-zero return value).
The immediate motivation for this is that a subsequent commit will
need to change all callers of the "*_get_value_multi()" family of
functions. In two cases here we (ab)used it to check whether we had
any values for the given key, but didn't care about the return value.
The rest of the callers here used various other config API functions
to do the same, all of which resolved to the same underlying functions
to provide the answer.
Some of these were using either git_config_get_string() or
git_config_get_string_tmp(), see fe4c750fb13 (submodule--helper: fix a
configure_added_submodule() leak, 2022-09-01) for a recent example. We
can now use a helper function that doesn't require a throwaway
variable.
We could have changed git_configset_get_value_multi() (and then
git_config_get_value() etc.) to accept a "NULL" as a "dest" for all
callers, but let's avoid changing the behavior of existing API
users. Having an "unused" value that we throw away internal to
config.c is cheap.
A "NULL as optional dest" pattern is also more fragile, as the intent
of the caller might be misinterpreted if he were to accidentally pass
"NULL", e.g. when "dest" is passed in from another function.
Another name for this function could have been
"*_config_key_exists()", as suggested in [1]. That would work for all
of these callers, and would currently be equivalent to this function,
as the git_configset_get_value() API normalizes all non-zero return
values to a "1".
But adding that API would set us up to lose information, as e.g. if
git_config_parse_key() in the underlying configset_find_element()
fails we'd like to return -1, not 1.
Let's change the underlying configset_find_element() function to
support this use-case, we'll make further use of it in a subsequent
commit where the git_configset_get_value_multi() function itself will
expose this new return value.
This still leaves various inconsistencies and clobbering or ignoring
of the return value in place. E.g here we're modifying
configset_add_value(), but ever since it was added in [2] we've been
ignoring its "int" return value, but as we're changing the
configset_find_element() it uses, let's have it faithfully ferry that
"ret" along.
Let's also use the "RESULT_MUST_BE_USED" macro introduced in [3] to
assert that we're checking the return value of
configset_find_element().
We're leaving the same change to configset_add_value() for some future
series. Once we start paying attention to its return value we'd need
to ferry it up as deep as do_config_from(), and would need to make
least read_{,very_}early_config() and git_protected_config() return an
"int" instead of "void". Let's leave that for now, and focus on
the *_get_*() functions.
1. 3c8687a73ee (add `config_set` API for caching config-like files, 2014-07-28)
2. https://lore.kernel.org/git/xmqqczadkq9f.fsf@gitster.g/
3. 1e8697b5c4e (submodule--helper: check repo{_submodule,}_init()
return values, 2022-09-01),
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 14:04:22 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Run only the discover part of the repo_config_get_*() functions
|
|
|
|
* below, in addition to 1 if not found, returns negative values on
|
|
|
|
* error (e.g. if the key itself is invalid).
|
|
|
|
*/
|
|
|
|
RESULT_MUST_BE_USED
|
|
|
|
int repo_config_get(struct repository *repo, const char *key);
|
2019-04-29 08:28:14 +00:00
|
|
|
int repo_config_get_value(struct repository *repo,
|
2019-04-29 08:28:23 +00:00
|
|
|
const char *key, const char **value);
|
2023-03-28 14:04:24 +00:00
|
|
|
RESULT_MUST_BE_USED
|
|
|
|
int repo_config_get_value_multi(struct repository *repo, const char *key,
|
|
|
|
const struct string_list **dest);
|
config API: add "string" version of *_value_multi(), fix segfaults
Fix numerous and mostly long-standing segfaults in consumers of
the *_config_*value_multi() API. As discussed in the preceding commit
an empty key in the config syntax yields a "NULL" string, which these
users would give to strcmp() (or similar), resulting in segfaults.
As this change shows, most users users of the *_config_*value_multi()
API didn't really want such an an unsafe and low-level API, let's give
them something with the safety of git_config_get_string() instead.
This fix is similar to what the *_string() functions and others
acquired in[1] and [2]. Namely introducing and using a safer
"*_get_string_multi()" variant of the low-level "_*value_multi()"
function.
This fixes segfaults in code introduced in:
- d811c8e17c6 (versionsort: support reorder prerelease suffixes, 2015-02-26)
- c026557a373 (versioncmp: generalize version sort suffix reordering, 2016-12-08)
- a086f921a72 (submodule: decouple url and submodule interest, 2017-03-17)
- a6be5e6764a (log: add log.excludeDecoration config option, 2020-04-16)
- 92156291ca8 (log: add default decoration filter, 2022-08-05)
- 50a044f1e40 (gc: replace config subprocesses with API calls, 2022-09-27)
There are now two users ofthe low-level API:
- One in "builtin/for-each-repo.c", which we'll convert in a
subsequent commit.
- The "t/helper/test-config.c" code added in [3].
As seen in the preceding commit we need to give the
"t/helper/test-config.c" caller these "NULL" entries.
We could also alter the underlying git_configset_get_value_multi()
function to be "string safe", but doing so would leave no room for
other variants of "*_get_value_multi()" that coerce to other types.
Such coercion can't be built on the string version, since as we've
established "NULL" is a true value in the boolean context, but if we
coerced it to "" for use in a list of strings it'll be subsequently
coerced to "false" as a boolean.
The callback pattern being used here will make it easy to introduce
e.g. a "multi" variant which coerces its values to "bool", "int",
"path" etc.
1. 40ea4ed9032 (Add config_error_nonbool() helper function,
2008-02-11)
2. 6c47d0e8f39 (config.c: guard config parser from value=NULL,
2008-02-11).
3. 4c715ebb96a (test-config: add tests for the config_set API,
2014-07-28)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 14:04:27 +00:00
|
|
|
RESULT_MUST_BE_USED
|
|
|
|
int repo_config_get_string_multi(struct repository *repo, const char *key,
|
|
|
|
const struct string_list **dest);
|
2019-04-29 08:28:14 +00:00
|
|
|
int repo_config_get_string(struct repository *repo,
|
2019-04-29 08:28:23 +00:00
|
|
|
const char *key, char **dest);
|
2020-08-14 16:17:36 +00:00
|
|
|
int repo_config_get_string_tmp(struct repository *repo,
|
|
|
|
const char *key, const char **dest);
|
2019-04-29 08:28:14 +00:00
|
|
|
int repo_config_get_int(struct repository *repo,
|
2019-04-29 08:28:23 +00:00
|
|
|
const char *key, int *dest);
|
2019-04-29 08:28:14 +00:00
|
|
|
int repo_config_get_ulong(struct repository *repo,
|
2019-04-29 08:28:23 +00:00
|
|
|
const char *key, unsigned long *dest);
|
2019-04-29 08:28:14 +00:00
|
|
|
int repo_config_get_bool(struct repository *repo,
|
2019-04-29 08:28:23 +00:00
|
|
|
const char *key, int *dest);
|
2019-04-29 08:28:14 +00:00
|
|
|
int repo_config_get_bool_or_int(struct repository *repo,
|
2019-04-29 08:28:23 +00:00
|
|
|
const char *key, int *is_bool, int *dest);
|
2019-04-29 08:28:14 +00:00
|
|
|
int repo_config_get_maybe_bool(struct repository *repo,
|
2017-06-22 18:43:42 +00:00
|
|
|
const char *key, int *dest);
|
2019-04-29 08:28:14 +00:00
|
|
|
int repo_config_get_pathname(struct repository *repo,
|
2019-04-29 08:28:23 +00:00
|
|
|
const char *key, const char **dest);
|
2017-06-22 18:43:42 +00:00
|
|
|
|
config: learn `git_protected_config()`
`uploadpack.packObjectsHook` is the only 'protected configuration only'
variable today, but we've noted that `safe.directory` and the upcoming
`safe.bareRepository` should also be 'protected configuration only'. So,
for consistency, we'd like to have a single implementation for protected
configuration.
The primary constraints are:
1. Reading from protected configuration should be fast. Nearly all "git"
commands inside a bare repository will read both `safe.directory` and
`safe.bareRepository`, so we cannot afford to be slow.
2. Protected configuration must be readable when the gitdir is not
known. `safe.directory` and `safe.bareRepository` both affect
repository discovery and the gitdir is not known at that point [1].
The chosen implementation in this commit is to read protected
configuration and cache the values in a global configset. This is
similar to the caching behavior we get with the_repository->config.
Introduce git_protected_config(), which reads protected configuration
and caches them in the global configset protected_config. Then, refactor
`uploadpack.packObjectsHook` to use git_protected_config().
The protected configuration functions are named similarly to their
non-protected counterparts, e.g. git_protected_config_check_init() vs
git_config_check_init().
In light of constraint 1, this implementation can still be improved.
git_protected_config() iterates through every variable in
protected_config, which is wasteful, but it makes the conversion simple
because it matches existing patterns. We will likely implement constant
time lookup functions for protected configuration in a future series
(such functions already exist for non-protected configuration, i.e.
repo_config_get_*()).
An alternative that avoids introducing another configset is to continue
to read all config using git_config(), but only accept values that have
the correct config scope [2]. This technically fulfills constraint 2,
because git_config() simply ignores the local and worktree config when
the gitdir is not known. However, this would read incomplete config into
the_repository->config, which would need to be reset when the gitdir is
known and git_config() needs to read the local and worktree config.
Resetting the_repository->config might be reasonable while we only have
these 'protected configuration only' variables, but it's not clear
whether this extends well to future variables.
[1] In this case, we do have a candidate gitdir though, so with a little
refactoring, it might be possible to provide a gitdir.
[2] This is how `uploadpack.packObjectsHook` was implemented prior to
this commit.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-14 21:27:59 +00:00
|
|
|
/*
|
|
|
|
* Functions for reading protected config. By definition, protected
|
|
|
|
* config ignores repository config, so these do not take a `struct
|
|
|
|
* repository` parameter.
|
|
|
|
*/
|
|
|
|
void git_protected_config(config_fn_t fn, void *data);
|
|
|
|
|
2019-10-23 05:30:52 +00:00
|
|
|
/**
|
|
|
|
* 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.
|
config API: add and use a "git_config_get()" family of functions
We already have the basic "git_config_get_value()" function and its
"repo_*" and "configset" siblings to get a given "key" and assign the
last key found to a provided "value".
But some callers don't care about that value, but just want to use the
return value of the "get_value()" function to check whether the key
exist (or another non-zero return value).
The immediate motivation for this is that a subsequent commit will
need to change all callers of the "*_get_value_multi()" family of
functions. In two cases here we (ab)used it to check whether we had
any values for the given key, but didn't care about the return value.
The rest of the callers here used various other config API functions
to do the same, all of which resolved to the same underlying functions
to provide the answer.
Some of these were using either git_config_get_string() or
git_config_get_string_tmp(), see fe4c750fb13 (submodule--helper: fix a
configure_added_submodule() leak, 2022-09-01) for a recent example. We
can now use a helper function that doesn't require a throwaway
variable.
We could have changed git_configset_get_value_multi() (and then
git_config_get_value() etc.) to accept a "NULL" as a "dest" for all
callers, but let's avoid changing the behavior of existing API
users. Having an "unused" value that we throw away internal to
config.c is cheap.
A "NULL as optional dest" pattern is also more fragile, as the intent
of the caller might be misinterpreted if he were to accidentally pass
"NULL", e.g. when "dest" is passed in from another function.
Another name for this function could have been
"*_config_key_exists()", as suggested in [1]. That would work for all
of these callers, and would currently be equivalent to this function,
as the git_configset_get_value() API normalizes all non-zero return
values to a "1".
But adding that API would set us up to lose information, as e.g. if
git_config_parse_key() in the underlying configset_find_element()
fails we'd like to return -1, not 1.
Let's change the underlying configset_find_element() function to
support this use-case, we'll make further use of it in a subsequent
commit where the git_configset_get_value_multi() function itself will
expose this new return value.
This still leaves various inconsistencies and clobbering or ignoring
of the return value in place. E.g here we're modifying
configset_add_value(), but ever since it was added in [2] we've been
ignoring its "int" return value, but as we're changing the
configset_find_element() it uses, let's have it faithfully ferry that
"ret" along.
Let's also use the "RESULT_MUST_BE_USED" macro introduced in [3] to
assert that we're checking the return value of
configset_find_element().
We're leaving the same change to configset_add_value() for some future
series. Once we start paying attention to its return value we'd need
to ferry it up as deep as do_config_from(), and would need to make
least read_{,very_}early_config() and git_protected_config() return an
"int" instead of "void". Let's leave that for now, and focus on
the *_get_*() functions.
1. 3c8687a73ee (add `config_set` API for caching config-like files, 2014-07-28)
2. https://lore.kernel.org/git/xmqqczadkq9f.fsf@gitster.g/
3. 1e8697b5c4e (submodule--helper: check repo{_submodule,}_init()
return values, 2022-09-01),
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 14:04:22 +00:00
|
|
|
*
|
|
|
|
* For those git_config_get*() functions that aren't documented,
|
|
|
|
* consult the corresponding repo_config_get*() function's
|
|
|
|
* documentation.
|
2019-10-23 05:30:52 +00:00
|
|
|
*/
|
|
|
|
|
config API: add and use a "git_config_get()" family of functions
We already have the basic "git_config_get_value()" function and its
"repo_*" and "configset" siblings to get a given "key" and assign the
last key found to a provided "value".
But some callers don't care about that value, but just want to use the
return value of the "get_value()" function to check whether the key
exist (or another non-zero return value).
The immediate motivation for this is that a subsequent commit will
need to change all callers of the "*_get_value_multi()" family of
functions. In two cases here we (ab)used it to check whether we had
any values for the given key, but didn't care about the return value.
The rest of the callers here used various other config API functions
to do the same, all of which resolved to the same underlying functions
to provide the answer.
Some of these were using either git_config_get_string() or
git_config_get_string_tmp(), see fe4c750fb13 (submodule--helper: fix a
configure_added_submodule() leak, 2022-09-01) for a recent example. We
can now use a helper function that doesn't require a throwaway
variable.
We could have changed git_configset_get_value_multi() (and then
git_config_get_value() etc.) to accept a "NULL" as a "dest" for all
callers, but let's avoid changing the behavior of existing API
users. Having an "unused" value that we throw away internal to
config.c is cheap.
A "NULL as optional dest" pattern is also more fragile, as the intent
of the caller might be misinterpreted if he were to accidentally pass
"NULL", e.g. when "dest" is passed in from another function.
Another name for this function could have been
"*_config_key_exists()", as suggested in [1]. That would work for all
of these callers, and would currently be equivalent to this function,
as the git_configset_get_value() API normalizes all non-zero return
values to a "1".
But adding that API would set us up to lose information, as e.g. if
git_config_parse_key() in the underlying configset_find_element()
fails we'd like to return -1, not 1.
Let's change the underlying configset_find_element() function to
support this use-case, we'll make further use of it in a subsequent
commit where the git_configset_get_value_multi() function itself will
expose this new return value.
This still leaves various inconsistencies and clobbering or ignoring
of the return value in place. E.g here we're modifying
configset_add_value(), but ever since it was added in [2] we've been
ignoring its "int" return value, but as we're changing the
configset_find_element() it uses, let's have it faithfully ferry that
"ret" along.
Let's also use the "RESULT_MUST_BE_USED" macro introduced in [3] to
assert that we're checking the return value of
configset_find_element().
We're leaving the same change to configset_add_value() for some future
series. Once we start paying attention to its return value we'd need
to ferry it up as deep as do_config_from(), and would need to make
least read_{,very_}early_config() and git_protected_config() return an
"int" instead of "void". Let's leave that for now, and focus on
the *_get_*() functions.
1. 3c8687a73ee (add `config_set` API for caching config-like files, 2014-07-28)
2. https://lore.kernel.org/git/xmqqczadkq9f.fsf@gitster.g/
3. 1e8697b5c4e (submodule--helper: check repo{_submodule,}_init()
return values, 2022-09-01),
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 14:04:22 +00:00
|
|
|
RESULT_MUST_BE_USED
|
|
|
|
int git_config_get(const char *key);
|
|
|
|
|
2019-10-23 05:30:52 +00:00
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_value(const char *key, const char **value);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Finds and returns the value list, sorted in order of increasing priority
|
|
|
|
* for the configuration variable `key`. When the configuration variable
|
2023-03-28 14:04:24 +00:00
|
|
|
* `key` is not found, returns 1 without touching `value`.
|
|
|
|
*
|
|
|
|
* The caller should not free or modify the returned pointer, as it is
|
|
|
|
* owned by the cache.
|
2019-10-23 05:30:52 +00:00
|
|
|
*/
|
2023-03-28 14:04:24 +00:00
|
|
|
RESULT_MUST_BE_USED
|
|
|
|
int git_config_get_value_multi(const char *key,
|
|
|
|
const struct string_list **dest);
|
config API: add "string" version of *_value_multi(), fix segfaults
Fix numerous and mostly long-standing segfaults in consumers of
the *_config_*value_multi() API. As discussed in the preceding commit
an empty key in the config syntax yields a "NULL" string, which these
users would give to strcmp() (or similar), resulting in segfaults.
As this change shows, most users users of the *_config_*value_multi()
API didn't really want such an an unsafe and low-level API, let's give
them something with the safety of git_config_get_string() instead.
This fix is similar to what the *_string() functions and others
acquired in[1] and [2]. Namely introducing and using a safer
"*_get_string_multi()" variant of the low-level "_*value_multi()"
function.
This fixes segfaults in code introduced in:
- d811c8e17c6 (versionsort: support reorder prerelease suffixes, 2015-02-26)
- c026557a373 (versioncmp: generalize version sort suffix reordering, 2016-12-08)
- a086f921a72 (submodule: decouple url and submodule interest, 2017-03-17)
- a6be5e6764a (log: add log.excludeDecoration config option, 2020-04-16)
- 92156291ca8 (log: add default decoration filter, 2022-08-05)
- 50a044f1e40 (gc: replace config subprocesses with API calls, 2022-09-27)
There are now two users ofthe low-level API:
- One in "builtin/for-each-repo.c", which we'll convert in a
subsequent commit.
- The "t/helper/test-config.c" code added in [3].
As seen in the preceding commit we need to give the
"t/helper/test-config.c" caller these "NULL" entries.
We could also alter the underlying git_configset_get_value_multi()
function to be "string safe", but doing so would leave no room for
other variants of "*_get_value_multi()" that coerce to other types.
Such coercion can't be built on the string version, since as we've
established "NULL" is a true value in the boolean context, but if we
coerced it to "" for use in a list of strings it'll be subsequently
coerced to "false" as a boolean.
The callback pattern being used here will make it easy to introduce
e.g. a "multi" variant which coerces its values to "bool", "int",
"path" etc.
1. 40ea4ed9032 (Add config_error_nonbool() helper function,
2008-02-11)
2. 6c47d0e8f39 (config.c: guard config parser from value=NULL,
2008-02-11).
3. 4c715ebb96a (test-config: add tests for the config_set API,
2014-07-28)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 14:04:27 +00:00
|
|
|
RESULT_MUST_BE_USED
|
|
|
|
int git_config_get_string_multi(const char *key,
|
|
|
|
const struct string_list **dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Resets and invalidates the config cache.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
void git_config_clear(void);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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`.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_string(const char *key, char **dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
2020-08-14 16:17:36 +00:00
|
|
|
/**
|
config: drop git_config_get_string_const()
As evidenced by the leak fixes in the previous commit, the "const" in
git_config_get_string_const() clearly misleads people into thinking that
it does not allocate a copy of the string. We can fix this by renaming
it, but it's easier still to just drop it. Of the four remaining
callers:
- The one in git_config_parse_expiry() still needs to allocate, since
that's what its callers expect. We can just use the non-const
version and cast our pointer. Slightly ugly, but the damage is
contained in one spot.
- The two in apply are writing to global "const char *" variables, and
need to continue allocating. We often mark these as const because we
assign default string literals to them. But in this case we don't do
that, so we can just declare them as real "char *" pointers and use
the non-const version.
- The call in checkout doesn't actually need a copy; it can just use
the non-allocating "tmp" version of the function.
The function is also mentioned in the MyFirstContribution document. We
can swap that call out for the non-allocating "tmp" variant, which fits
well in the example given.
We'll drop the "configset" and "repo" variants, as well (which are
unused).
Note that this frees up the "const" name, so we could rename the "tmp"
variant back to that. But let's give some time for topics in flight to
adapt to the new code before doing so (if we do it too soon, the
function semantics will change but the compiler won't alert us).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-17 21:33:11 +00:00
|
|
|
* Similar to `git_config_get_string`, but does not allocate any new
|
2020-08-14 16:17:36 +00:00
|
|
|
* memory; on success `dest` will point to memory owned by the config
|
|
|
|
* machinery, which could be invalidated if it is discarded and reloaded.
|
|
|
|
*/
|
|
|
|
int git_config_get_string_tmp(const char *key, const char **dest);
|
|
|
|
|
2019-10-23 05:30:52 +00:00
|
|
|
/**
|
|
|
|
* 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`.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_int(const char *key, int *dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Similar to `git_config_get_int` but for unsigned longs.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_ulong(const char *key, unsigned long *dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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`.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_bool(const char *key, int *dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Similar to `git_config_get_bool`, except that integers are copied as-is,
|
|
|
|
* and `is_bool` flag is unset.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Similar to `git_config_get_bool`, except that it returns -1 on error
|
|
|
|
* rather than dying.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_maybe_bool(const char *key, int *dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Similar to `git_config_get_string`, but expands `~` or `~user` into
|
|
|
|
* the user's home directory when found at the beginning of the path.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_pathname(const char *key, const char **dest);
|
2019-10-23 05:30:52 +00:00
|
|
|
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_index_threads(int *dest);
|
|
|
|
int git_config_get_split_index(void);
|
|
|
|
int git_config_get_max_percent_split_change(void);
|
2017-06-14 18:07:34 +00:00
|
|
|
|
|
|
|
/* This dies if the configured or default date is in the future */
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_expiry(const char *key, const char **output);
|
2017-06-14 18:07:34 +00:00
|
|
|
|
2017-08-19 18:43:39 +00:00
|
|
|
/* parse either "this many days" integer, or "5.days.ago" approxidate */
|
2019-04-29 08:28:14 +00:00
|
|
|
int git_config_get_expiry_in_days(const char *key, timestamp_t *, timestamp_t now);
|
2017-08-19 18:43:39 +00:00
|
|
|
|
2019-10-23 05:30:52 +00:00
|
|
|
/**
|
|
|
|
* 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`.
|
|
|
|
*/
|
2019-04-29 08:28:20 +00:00
|
|
|
NORETURN void git_die_config(const char *key, const char *err, ...) __attribute__((format(printf, 2, 3)));
|
2019-10-23 05:30:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
NORETURN void git_die_config_linenr(const char *key, const char *filename, int linenr);
|
2017-06-14 18:07:34 +00:00
|
|
|
|
2018-05-26 13:55:21 +00:00
|
|
|
#define LOOKUP_CONFIG(mapping, var) \
|
|
|
|
lookup_config(mapping, ARRAY_SIZE(mapping), var)
|
|
|
|
int lookup_config(const char **mapping, int nr_mapping, const char *var);
|
|
|
|
|
2017-06-14 18:07:34 +00:00
|
|
|
#endif /* CONFIG_H */
|