{"thread":{"id":"52062","subject":"[PATCH 0/1] config: add documentation to config.h","startedAt":"2019-10-18T00:07:22Z","lastAt":"2019-10-24T02:14:38Z","messageCount":16,"participants":["Heba Waly via GitGitGadget","Jonathan Tan","Emily Shaffer","Heba Waly","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"384323","messageId":"pull.405.git.1571357219.gitgitgadget@gmail.com","threadId":"52062","inReplyTo":null,"subject":"[PATCH 0/1] config: add documentation to config.h","fromName":"Heba Waly via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-10-18T00:06:58Z","receivedAt":"2019-10-18T00:07:22Z","isPatch":true,"sender":{"key":"heba.waly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1539076?v=4"},"body":"This commit is copying and summarizing the documentation from\ndocumentation/technical/api-config.txt to comments in config.h\n\nSigned-off-by: Heba Waly heba.waly@gmail.com [heba.waly@gmail.com]\n\nThanks for taking the time to contribute to Git! Please be advised that the\nGit community does not use github.com for their contributions. Instead, we\nuse a mailing list (git@vger.kernel.org) for code submissions, code reviews,\nand bug reports. Nevertheless, you can use GitGitGadget (\nhttps://gitgitgadget.github.io/) to conveniently send your Pull Requests\ncommits to our mailing list.\n\nPlease read the \"guidelines for contributing\" linked above!\n\nHeba Waly (1):\n config: add documentation to config.h\n\n config.h | 327 +++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 327 insertions(+)\n\n\nbase-commit: 108b97dc372828f0e72e56bbb40cae8e1e83ece6\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-405%2FHebaWaly%2Fconfig_documentation-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-405/HebaWaly/config_documentation-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/405\n-- \ngitgitgadget\n"},{"id":"384324","messageId":"2e42eafb5db6192829e9e206e9e9905b31f8e8a6.1571357219.git.gitgitgadget@gmail.com","threadId":"52062","inReplyTo":"pull.405.git.1571357219.gitgitgadget@gmail.com","subject":"[PATCH 1/1] config: add documentation to config.h","fromName":"Heba Waly via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-10-18T00:06:59Z","receivedAt":"2019-10-18T00:07:22Z","isPatch":true,"sender":{"key":"heba.waly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1539076?v=4"},"body":"From: Heba Waly \n\nThis commit is copying and summarizing the documentation from\ndocumentation/technical/api-config.txt to comments in config.h\n\nSigned-off-by: Heba Waly \n---\n config.h | 327 +++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 327 insertions(+)\n\ndiff --git a/config.h b/config.h\nindex f0ed464004..fa999a2ba0 100644\n--- a/config.h\n+++ b/config.h\n@@ -4,6 +4,40 @@\n #include \"hashmap.h\"\n #include \"string-list.h\"\n \n+\n+/**\n+ * The config API gives callers a way to access Git configuration files\n+ * (and files which have the same syntax). See linkgit:git-config[1] for a\n+ * discussion of the config file syntax.\n+ *\n+ * General Usage\n+ * -------------\n+ *\n+ * Config files are parsed linearly, and each variable found is passed to a\n+ * caller-provided callback function. The callback function is responsible\n+ * for any actions to be taken on the config option, and is free to ignore\n+ * some options. It is not uncommon for the configuration to be parsed\n+ * several times during the run of a Git program, with different callbacks\n+ * picking out different variables useful to themselves.\n+ *\n+ * A config callback function takes three parameters:\n+ *\n+ * - the name of the parsed variable. This is in canonical \"flat\" form: the\n+ * section, subsection, and variable segments will be separated by dots,\n+ * and the section and variable segments will be all lowercase. E.g.,\n+ * `core.ignorecase`, `diff.SomeType.textconv`.\n+ *\n+ * - the value of the found variable, as a string. If the variable had no\n+ * value specified, the value will be NULL (typically this means it\n+ * should be interpreted as boolean true).\n+ *\n+ * - a void pointer passed in by the caller of the config API; this can\n+ * contain callback-specific data\n+ *\n+ * A config callback should return 0 for success, or -1 if the variable\n+ * could not be parsed properly.\n+ */\n+\n struct object_id;\n \n /* git_config_parse_key() returns these negated: */\n@@ -73,6 +107,11 @@ struct config_options {\n \n typedef int (*config_fn_t)(const char *, const char *, void *);\n int git_default_config(const char *, const char *, void *);\n+\n+/**\n+ * Read a specific file in git-config format.\n+ * This function takes the same callback and data parameters as `git_config`.\n+ */\n int git_config_from_file(config_fn_t fn, const char *, void *);\n int git_config_from_file_with_options(config_fn_t fn, const char *,\n \t\t\t\t void *,\n@@ -88,33 +127,152 @@ void git_config_push_parameter(const char *text);\n int git_config_from_parameters(config_fn_t fn, void *data);\n void read_early_config(config_fn_t cb, void *data);\n void read_very_early_config(config_fn_t cb, void *data);\n+\n+/**\n+ * Most programs will simply want to look up variables in all config files\n+ * that Git knows about, using the normal precedence rules. To do this,\n+ * call `git_config` with a callback function and void data pointer.\n+ *\n+ * `git_config` will read all config sources in order of increasing\n+ * priority. Thus a callback should typically overwrite previously-seen\n+ * entries with new ones (e.g., if both the user-wide `~/.gitconfig` and\n+ * repo-specific `.git/config` contain `color.ui`, the config machinery\n+ * will first feed the user-wide one to the callback, and then the\n+ * repo-specific one; by overwriting, the higher-priority repo-specific\n+ * value is left at the end).\n+ */\n void git_config(config_fn_t fn, void *);\n+\n+/**\n+ * Lets the caller examine config while adjusting some of the default\n+ * behavior of `git_config`. It should almost never be used by \"regular\"\n+ * Git code that is looking up configuration variables.\n+ * It is intended for advanced callers like `git-config`, which are\n+ * intentionally tweaking the normal config-lookup process.\n+ * It takes two extra parameters:\n+ *\n+ * `config_source`::\n+ * If this parameter is non-NULL, it specifies the source to parse for\n+ * configuration, rather than looking in the usual files. See `struct\n+ * git_config_source` in `config.h` for details. Regular `git_config` defaults\n+ * to `NULL`.\n+ *\n+ * `opts`::\n+ * Specify options to adjust the behavior of parsing config files. See `struct\n+ * config_options` in `config.h` for details. As an example: regular `git_config`\n+ * sets `opts.respect_includes` to `1` by default.\n+ */\n int config_with_options(config_fn_t fn, void *,\n \t\t\tstruct git_config_source *config_source,\n \t\t\tconst struct config_options *opts);\n+\n+/**\n+ * Value Parsing Helpers\n+ * ---------------------\n+ *\n+ * To aid in parsing string values, the config API provides callbacks with\n+ * a number of helper functions\n+ */\n+\n int git_parse_ssize_t(const char *, ssize_t *);\n int git_parse_ulong(const char *, unsigned long *);\n+\n+/**\n+ * Same as `git_config_bool`, except that it returns -1 on error rather\n+ * than dying.\n+ */\n int git_parse_maybe_bool(const char *);\n+\n+/**\n+ * Parse the string to an integer, including unit factors. Dies on error;\n+ * otherwise, returns the parsed result.\n+ */\n int git_config_int(const char *, const char *);\n int64_t git_config_int64(const char *, const char *);\n+\n+/**\n+ * Identical to `git_config_int`, but for unsigned longs.\n+ */\n unsigned long git_config_ulong(const char *, const char *);\n ssize_t git_config_ssize_t(const char *, const char *);\n+\n+/**\n+ * Same as `git_config_bool`, except that integers are returned as-is, and\n+ * an `is_bool` flag is unset.\n+ */\n int git_config_bool_or_int(const char *, const char *, int *);\n+\n+/**\n+ * Parse a string into a boolean value, respecting keywords like \"true\" and\n+ * \"false\". Integer values are converted into true/false values (when they\n+ * are non-zero or zero, respectively). Other values cause a die(). If\n+ * parsing is successful, the return value is the result.\n+ */\n int git_config_bool(const char *, const char *);\n+\n+/**\n+ * Allocates and copies the value string into the `dest` parameter; if no\n+ * string is given, prints an error message and returns -1.\n+ */\n int git_config_string(const char **, const char *, const char *);\n+\n+/**\n+ * Similar to `git_config_string`, but expands `~` or `~user` into the\n+ * user's home directory when found at the beginning of the path.\n+ */\n int git_config_pathname(const char **, const char *, const char *);\n int git_config_expiry_date(timestamp_t *, const char *, const char *);\n int git_config_color(char *, const char *, const char *);\n int git_config_set_in_file_gently(const char *, const char *, const char *);\n+\n+/**\n+ * write config values to a specific config file\n+ * takes a key/value pair as parameter.\n+ */\n void git_config_set_in_file(const char *, const char *, const char *);\n int git_config_set_gently(const char *, const char *);\n+\n+/**\n+ * write config values to `.git/config`\n+ * takes a key/value pair as parameter.\n+ */\n void git_config_set(const char *, const char *);\n int git_config_parse_key(const char *, char **, int *);\n int git_config_key_is_valid(const char *key);\n int git_config_set_multivar_gently(const char *, const char *, const char *, int);\n void git_config_set_multivar(const char *, const char *, const char *, int);\n int git_config_set_multivar_in_file_gently(const char *, const char *, const char *, const char *, int);\n+\n+/**\n+ * takes four parameters:\n+ *\n+ * - the name of the file, as a string, to which key/value pairs will be written.\n+ *\n+ * - the name of key, as a string. This is in canonical \"flat\" form: the section,\n+ * subsection, and variable segments will be separated by dots, and the section\n+ * and variable segments will be all lowercase.\n+ * E.g., `core.ignorecase`, `diff.SomeType.textconv`.\n+ *\n+ * - the value of the variable, as a string. If value is equal to NULL, it will\n+ * remove the matching key from the config file.\n+ *\n+ * - the value regex, as a string. It will disregard key/value pairs where value\n+ * does not match.\n+ *\n+ * - a multi_replace value, as an int. If value is equal to zero, nothing or only\n+ * one matching key/value is replaced, else all matching key/values (regardless\n+ * how many) are removed, before the new pair is written.\n+ *\n+ * It returns 0 on success.\n+ */\n void git_config_set_multivar_in_file(const char *, const char *, const char *, const char *, int);\n+\n+/**\n+ * rename or remove sections in the config file\n+ * parameters `old_name` and `new_name`\n+ * If NULL is passed through `new_name` parameter,\n+ * the section will be removed from the config file.\n+ */\n int git_config_rename_section(const char *, const char *);\n int git_config_rename_section_in_file(const char *, const char *, const char *);\n int git_config_copy_section(const char *, const char *);\n@@ -142,6 +300,30 @@ enum config_scope current_config_scope(void);\n const char *current_config_origin_type(void);\n const char *current_config_name(void);\n \n+/**\n+ * Include Directives\n+ * ------------------\n+ *\n+ * By default, the config parser does not respect include directives.\n+ * However, a caller can use the special `git_config_include` wrapper\n+ * callback to support them. To do so, you simply wrap your \"real\" callback\n+ * function and data pointer in a `struct config_include_data`, and pass\n+ * the wrapper to the regular config-reading functions. For example:\n+ *\n+ * -------------------------------------------\n+ * int read_file_with_include(const char *file, config_fn_t fn, void *data)\n+ * {\n+ * struct config_include_data inc = CONFIG_INCLUDE_INIT;\n+ * inc.fn = fn;\n+ * inc.data = data;\n+ * return git_config_from_file(git_config_include, file, &inc);\n+ * }\n+ * -------------------------------------------\n+ *\n+ * `git_config` respects includes automatically. The lower-level\n+ * `git_config_from_file` does not.\n+ *\n+ */\n struct config_include_data {\n \tint depth;\n \tconfig_fn_t fn;\n@@ -169,6 +351,33 @@ int parse_config_key(const char *var,\n \t\t const char **subsection, int *subsection_len,\n \t\t const char **key);\n \n+/**\n+ * Custom Configsets\n+ * -----------------\n+ *\n+ * A `config_set` can be used to construct an in-memory cache for\n+ * config-like files that the caller specifies (i.e., files like `.gitmodules`,\n+ * `~/.gitconfig` etc.). For example,\n+ *\n+ * ----------------------------------------\n+ * struct config_set gm_config;\n+ * git_configset_init(&gm_config);\n+ * int b;\n+ * //we add config files to the config_set\n+ * git_configset_add_file(&gm_config, \".gitmodules\");\n+ * git_configset_add_file(&gm_config, \".gitmodules_alt\");\n+ *\n+ * if (!git_configset_get_bool(gm_config, \"submodule.frotz.ignore\", &b)) {\n+ * //hack hack hack\n+ * }\n+ *\n+ * when we are done with the configset:\n+ * git_configset_clear(&gm_config);\n+ * ----------------------------------------\n+ *\n+ * Configset API provides functions for the above mentioned work flow\n+ */\n+\n struct config_set_element {\n \tstruct hashmap_entry ent;\n \tchar *key;\n@@ -197,15 +406,45 @@ struct config_set {\n \tstruct configset_list list;\n };\n \n+/**\n+ * Initializes the config_set `cs`.\n+ */\n void git_configset_init(struct config_set *cs);\n+\n+/**\n+ * Parses the file and adds the variable-value pairs to the `config_set`,\n+ * dies if there is an error in parsing the file. Returns 0 on success, or\n+ * -1 if the file does not exist or is inaccessible. The user has to decide\n+ * if he wants to free the incomplete configset or continue using it when\n+ * the function returns -1.\n+ */\n int git_configset_add_file(struct config_set *cs, const char *filename);\n+\n+/**\n+ * Finds and returns the value list, sorted in order of increasing priority\n+ * for the configuration variable `key` and config set `cs`. When the\n+ * configuration variable `key` is not found, returns NULL. The caller\n+ * should not free or modify the returned pointer, as it is owned by the cache.\n+ */\n const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key);\n+\n+/**\n+ * Clears `config_set` structure, removes all saved variable-value pairs.\n+ */\n void git_configset_clear(struct config_set *cs);\n \n /*\n * These functions return 1 if not found, and 0 if found, leaving the found\n * value in the 'dest' pointer.\n */\n+\n+/*\n+ * Finds the highest-priority value for the configuration variable `key`\n+ * and config set `cs`, stores the pointer to it in `value` and returns 0.\n+ * When the configuration variable `key` is not found, returns 1 without\n+ * touching `value`. The caller should not free or modify `value`, as it\n+ * is owned by the cache.\n+ */\n int git_configset_get_value(struct config_set *cs, const char *key, const char **dest);\n int git_configset_get_string_const(struct config_set *cs, const char *key, const char **dest);\n int git_configset_get_string(struct config_set *cs, const char *key, char **dest);\n@@ -240,16 +479,92 @@ int repo_config_get_maybe_bool(struct repository *repo,\n int repo_config_get_pathname(struct repository *repo,\n \t\t\t const char *key, const char **dest);\n \n+/**\n+ * Querying For Specific Variables\n+ * -------------------------------\n+ *\n+ * For programs wanting to query for specific variables in a non-callback\n+ * manner, the config API provides two functions `git_config_get_value`\n+ * and `git_config_get_value_multi`. They both read values from an internal\n+ * cache generated previously from reading the config files.\n+ */\n+\n+/**\n+ * Finds the highest-priority value for the configuration variable `key`,\n+ * stores the pointer to it in `value` and returns 0. When the\n+ * configuration variable `key` is not found, returns 1 without touching\n+ * `value`. The caller should not free or modify `value`, as it is owned\n+ * by the cache.\n+ */\n int git_config_get_value(const char *key, const char **value);\n+\n+/**\n+ * Finds and returns the value list, sorted in order of increasing priority\n+ * for the configuration variable `key`. When the configuration variable\n+ * `key` is not found, returns NULL. The caller should not free or modify\n+ * the returned pointer, as it is owned by the cache.\n+ */\n const struct string_list *git_config_get_value_multi(const char *key);\n+\n+/**\n+ * Resets and invalidates the config cache.\n+ */\n void git_config_clear(void);\n+\n+/**\n+ * Allocates and copies the retrieved string into the `dest` parameter for\n+ * the configuration variable `key`; if NULL string is given, prints an\n+ * error message and returns -1. When the configuration variable `key` is\n+ * not found, returns 1 without touching `dest`.\n+ */\n int git_config_get_string_const(const char *key, const char **dest);\n+\n+/**\n+ * Similar to `git_config_get_string_const`, except that retrieved value\n+ * copied into the `dest` parameter is a mutable string.\n+ */\n int git_config_get_string(const char *key, char **dest);\n+\n+/**\n+ * Finds and parses the value to an integer for the configuration variable\n+ * `key`. Dies on error; otherwise, stores the value of the parsed integer in\n+ * `dest` and returns 0. When the configuration variable `key` is not found,\n+ * returns 1 without touching `dest`.\n+ */\n int git_config_get_int(const char *key, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_int` but for unsigned longs.\n+ */\n int git_config_get_ulong(const char *key, unsigned long *dest);\n+\n+/**\n+ * Finds and parses the value into a boolean value, for the configuration\n+ * variable `key` respecting keywords like \"true\" and \"false\". Integer\n+ * values are converted into true/false values (when they are non-zero or\n+ * zero, respectively). Other values cause a die(). If parsing is successful,\n+ * stores the value of the parsed result in `dest` and returns 0. When the\n+ * configuration variable `key` is not found, returns 1 without touching\n+ * `dest`.\n+ */\n int git_config_get_bool(const char *key, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_bool`, except that integers are copied as-is,\n+ * and `is_bool` flag is unset.\n+ */\n int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_bool`, except that it returns -1 on error\n+ * rather than dying.\n+ */\n int git_config_get_maybe_bool(const char *key, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_string`, but expands `~` or `~user` into\n+ * the user's home directory when found at the beginning of the path.\n+ */\n int git_config_get_pathname(const char *key, const char **dest);\n int git_config_get_index_threads(int *dest);\n int git_config_get_untracked_cache(void);\n@@ -270,7 +585,19 @@ struct key_value_info {\n \tenum config_scope scope;\n };\n \n+/**\n+ * First prints the error message specified by the caller in `err` and then\n+ * dies printing the line number and the file name of the highest priority\n+ * value for the configuration variable `key`.\n+ */\n NORETURN void git_die_config(const char *key, const char *err, ...) __attribute__((format(printf, 2, 3)));\n+\n+/**\n+ * Helper function which formats the die error message according to the\n+ * parameters entered. Used by `git_die_config()`. It can be used by callers\n+ * handling `git_config_get_value_multi()` to print the correct error message\n+ * for the desired value.\n+ */\n NORETURN void git_die_config_linenr(const char *key, const char *filename, int linenr);\n \n #define LOOKUP_CONFIG(mapping, var) \\\n-- \ngitgitgadget\n"},{"id":"384434","messageId":"20191018220705.241778-1-jonathantanmy@google.com","threadId":"52062","inReplyTo":"2e42eafb5db6192829e9e206e9e9905b31f8e8a6.1571357219.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 1/1] config: add documentation to config.h","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2019-10-18T22:07:05Z","receivedAt":"2019-10-18T22:18:38Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"> From: Heba Waly \n> \n> This commit is copying and summarizing the documentation from\n> documentation/technical/api-config.txt to comments in config.h\n\nThanks for this commit!\n\nAs for your commit message, as far as I know, the idea is to move the\ndocumentation, not to copy it. Also, write this in imperative form,\ne.g.:\n\n Move the documentation from Documentation/technical/api-config.txt\n into config.h.\n\nAlso change the title of the commit message accordingly, e.g.:\n\n config: move documentation to header file\n\nAlso, include the deletion of api-config.txt in this commit.\n\nIf you are doing any summarizing, describe what summarizing you are\ndoing in the commit message too.\n\n> + * A config callback function takes three parameters:\n> + *\n> + * - the name of the parsed variable. This is in canonical \"flat\" form: the\n> + * section, subsection, and variable segments will be separated by dots,\n> + * and the section and variable segments will be all lowercase. E.g.,\n> + * `core.ignorecase`, `diff.SomeType.textconv`.\n> + *\n> + * - the value of the found variable, as a string. If the variable had no\n> + * value specified, the value will be NULL (typically this means it\n> + * should be interpreted as boolean true).\n> + *\n> + * - a void pointer passed in by the caller of the config API; this can\n> + * contain callback-specific data\n> + *\n> + * A config callback should return 0 for success, or -1 if the variable\n> + * could not be parsed properly.\n> + */\n> +\n> struct object_id;\n> \n> /* git_config_parse_key() returns these negated: */\n> @@ -73,6 +107,11 @@ struct config_options {\n> \n> typedef int (*config_fn_t)(const char *, const char *, void *);\n> int git_default_config(const char *, const char *, void *);\n\nThe config callback is config_fn_t so that documentation should be\nplaced above that typedef.\n\nOther than that, this looks good to me. The result is perhaps not as\ntidy as we would like (especially with some functions being documented\nand others not) but I think, anyway, that a verbatim movement should be\ndone in one commit (this one) and improvements, in a subsequent commit.\n"},{"id":"384436","messageId":"20191018225155.GA9323@google.com","threadId":"52062","inReplyTo":"2e42eafb5db6192829e9e206e9e9905b31f8e8a6.1571357219.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 1/1] config: add documentation to config.h","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-18T22:51:55Z","receivedAt":"2019-10-18T22:52:03Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Fri, Oct 18, 2019 at 12:06:59AM +0000, Heba Waly via GitGitGadget wrote:\n> From: Heba Waly \n\nHi Heba,\n\nThanks for the patch!\n\nI'd like to highlight to the community that this is an Outreachy\napplicant and microproject. Heba, when you send the next version, I\nthink you can add [Outreachy] manually to the PR subject line - that\nshould draw the attention of those in the community who are invested in\nhelping Outreachy applicants.\n\n> \n> This commit is copying and summarizing the documentation from\n> documentation/technical/api-config.txt to comments in config.h\n\nI think in the GitGitGadget PR you've got some great comments from Dscho\nabout how to format your commit message; please take a look at those and\nfeel free to reach out to me if you're still not sure what's missing or\nnot.\n\n> Signed-off-by: Heba Waly \n\nOne thing I miss in this change is the removal of the contents of\nDocumentation/technical/api-config.txt (or maybe the removal of the file\nitself). I'd prefer to see at least for api-config.txt to say something\nlike \"Please refer to comments in 'config.h'\"; or, more drastically, for\napi-config.txt to be removed entirely.\n\nHaving both pieces of documentation standing independently means that\nsomeone who's trying to add new information about the config API won't\nknow where to add it; eventually they'll add something to config.h but\nnot api-config.txt, or vice versa, and the two documents will go out of\nsync. So we want to move the documentation, rather than copy it.\n\nPlus, having the removed doc as part of this change means I can more\neasily look at where the lines of content are coming from and see if you\nmade any significant changes from the old contents of api-config.txt.\nHaving a smaller amount of change to review means your review will be\nquicker - I don't feel as strong a need to check the grammar, spelling,\netc, because that text has already been reviewed before, and can just\nmake sure that the placement of each piece of documentation makes sense.\n\n\n> ---\n> config.h | 327 +++++++++++++++++++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 327 insertions(+)\n> \n> diff --git a/config.h b/config.h\n> index f0ed464004..fa999a2ba0 100644\n> --- a/config.h\n> +++ b/config.h\n> @@ -4,6 +4,40 @@\n> #include \"hashmap.h\"\n> #include \"string-list.h\"\n> \n> +\n> +/**\n> + * The config API gives callers a way to access Git configuration files\n> + * (and files which have the same syntax). See linkgit:git-config[1] for a\n> + * discussion of the config file syntax.\n> + *\n> + * General Usage\n> + * -------------\n> + *\n> + * Config files are parsed linearly, and each variable found is passed to a\n> + * caller-provided callback function. The callback function is responsible\n> + * for any actions to be taken on the config option, and is free to ignore\n> + * some options. It is not uncommon for the configuration to be parsed\n> + * several times during the run of a Git program, with different callbacks\n> + * picking out different variables useful to themselves.\n> + *\n> + * A config callback function takes three parameters:\n> + *\n> + * - the name of the parsed variable. This is in canonical \"flat\" form: the\n> + * section, subsection, and variable segments will be separated by dots,\n> + * and the section and variable segments will be all lowercase. E.g.,\n> + * `core.ignorecase`, `diff.SomeType.textconv`.\n> + *\n> + * - the value of the found variable, as a string. If the variable had no\n> + * value specified, the value will be NULL (typically this means it\n> + * should be interpreted as boolean true).\n> + *\n> + * - a void pointer passed in by the caller of the config API; this can\n> + * contain callback-specific data\n> + *\n> + * A config callback should return 0 for success, or -1 if the variable\n> + * could not be parsed properly.\n> + */\n> +\n> struct object_id;\n> \n> /* git_config_parse_key() returns these negated: */\n> @@ -73,6 +107,11 @@ struct config_options {\n> \n> typedef int (*config_fn_t)(const char *, const char *, void *);\n> int git_default_config(const char *, const char *, void *);\n> +\n> +/**\n> + * Read a specific file in git-config format.\n> + * This function takes the same callback and data parameters as `git_config`.\n> + */\n> int git_config_from_file(config_fn_t fn, const char *, void *);\n> int git_config_from_file_with_options(config_fn_t fn, const char *,\n> \t\t\t\t void *,\n> @@ -88,33 +127,152 @@ void git_config_push_parameter(const char *text);\n> int git_config_from_parameters(config_fn_t fn, void *data);\n> void read_early_config(config_fn_t cb, void *data);\n> void read_very_early_config(config_fn_t cb, void *data);\n> +\n> +/**\n> + * Most programs will simply want to look up variables in all config files\n> + * that Git knows about, using the normal precedence rules. To do this,\n> + * call `git_config` with a callback function and void data pointer.\n> + *\n> + * `git_config` will read all config sources in order of increasing\n> + * priority. Thus a callback should typically overwrite previously-seen\n> + * entries with new ones (e.g., if both the user-wide `~/.gitconfig` and\n> + * repo-specific `.git/config` contain `color.ui`, the config machinery\n> + * will first feed the user-wide one to the callback, and then the\n> + * repo-specific one; by overwriting, the higher-priority repo-specific\n> + * value is left at the end).\n> + */\n> void git_config(config_fn_t fn, void *);\n> +\n> +/**\n> + * Lets the caller examine config while adjusting some of the default\n> + * behavior of `git_config`. It should almost never be used by \"regular\"\n> + * Git code that is looking up configuration variables.\n> + * It is intended for advanced callers like `git-config`, which are\n> + * intentionally tweaking the normal config-lookup process.\n> + * It takes two extra parameters:\n> + *\n> + * `config_source`::\n\nI think the wonky trailing \"::\" is for generating manpages/HTML out of\nthe asciidoc from the original api-config.txt. I expect it's OK to\nremove them throughout this change and format this in a way that makes more\nsense for comments which won't be converted into anything else.\n\n> + * If this parameter is non-NULL, it specifies the source to parse for\n> + * configuration, rather than looking in the usual files. See `struct\n> + * git_config_source` in `config.h` for details. Regular `git_config` defaults\n> + * to `NULL`.\n> + *\n> + * `opts`::\n> + * Specify options to adjust the behavior of parsing config files. See `struct\n> + * config_options` in `config.h` for details. As an example: regular `git_config`\n> + * sets `opts.respect_includes` to `1` by default.\n> + */\n> int config_with_options(config_fn_t fn, void *,\n> \t\t\tstruct git_config_source *config_source,\n> \t\t\tconst struct config_options *opts);\n> +\n> +/**\n> + * Value Parsing Helpers\n> + * ---------------------\n\nIt may not make sense to have the header here in the middle of the doc.\n\nI wonder whether we need the headers at all anymore; or, whether it\nmakes more sense to put this header in the long comment at the top with\njust the list of function names (so someone knows where to look), and\nleave the per-function explanations inline with the function they\ndescribe?\n\n> + *\n> + * To aid in parsing string values, the config API provides callbacks with\n> + * a number of helper functions\n\nIn the copy paste, this lost some ending punctuation. I'd advocate\nending this with \":\" to indicate \"we are about to give the list of those\nfunctions\". Although, I wonder whether it makes more sense to rephrase\nthis into something like \"The following helper functions aid in parsing\nstring values:\"? Not sure.\n\n> + */\n> +\n> int git_parse_ssize_t(const char *, ssize_t *);\n> int git_parse_ulong(const char *, unsigned long *);\n> +\n> +/**\n> + * Same as `git_config_bool`, except that it returns -1 on error rather\n> + * than dying.\n> + */\n> int git_parse_maybe_bool(const char *);\n> +\n> +/**\n> + * Parse the string to an integer, including unit factors. Dies on error;\n> + * otherwise, returns the parsed result.\n> + */\n> int git_config_int(const char *, const char *);\n> int64_t git_config_int64(const char *, const char *);\n> +\n> +/**\n> + * Identical to `git_config_int`, but for unsigned longs.\n> + */\n> unsigned long git_config_ulong(const char *, const char *);\n> ssize_t git_config_ssize_t(const char *, const char *);\n> +\n> +/**\n> + * Same as `git_config_bool`, except that integers are returned as-is, and\n> + * an `is_bool` flag is unset.\n> + */\n> int git_config_bool_or_int(const char *, const char *, int *);\n> +\n> +/**\n> + * Parse a string into a boolean value, respecting keywords like \"true\" and\n> + * \"false\". Integer values are converted into true/false values (when they\n> + * are non-zero or zero, respectively). Other values cause a die(). If\n> + * parsing is successful, the return value is the result.\n> + */\n> int git_config_bool(const char *, const char *);\n> +\n> +/**\n> + * Allocates and copies the value string into the `dest` parameter; if no\n> + * string is given, prints an error message and returns -1.\n> + */\n> int git_config_string(const char **, const char *, const char *);\n> +\n> +/**\n> + * Similar to `git_config_string`, but expands `~` or `~user` into the\n> + * user's home directory when found at the beginning of the path.\n> + */\n> int git_config_pathname(const char **, const char *, const char *);\n\nI might like to see another space under this function so it's clear\nthat the description isn't talking about expiry, color, or\nset_in_file_gently. There are other places where this comment applies,\ntoo.\n\n> int git_config_expiry_date(timestamp_t *, const char *, const char *);\n> int git_config_color(char *, const char *, const char *);\n> int git_config_set_in_file_gently(const char *, const char *, const char *);\n> +\n> +/**\n> + * write config values to a specific config file\n> + * takes a key/value pair as parameter.\n> + */\n\nYou could reflow this comment and some others so that they extend closer\nto the end of the 80c line width; in some cases you can condense the\ncomment to a single line this way :)\n\n> void git_config_set_in_file(const char *, const char *, const char *);\n> int git_config_set_gently(const char *, const char *);\n> +\n> +/**\n> + * write config values to `.git/config`\n> + * takes a key/value pair as parameter.\n> + */\n> void git_config_set(const char *, const char *);\n> int git_config_parse_key(const char *, char **, int *);\n> int git_config_key_is_valid(const char *key);\n> int git_config_set_multivar_gently(const char *, const char *, const char *, int);\n> void git_config_set_multivar(const char *, const char *, const char *, int);\n> int git_config_set_multivar_in_file_gently(const char *, const char *, const char *, const char *, int);\n> +\n> +/**\n> + * takes four parameters:\n> + *\n> + * - the name of the file, as a string, to which key/value pairs will be written.\n> + *\n> + * - the name of key, as a string. This is in canonical \"flat\" form: the section,\n> + * subsection, and variable segments will be separated by dots, and the section\n> + * and variable segments will be all lowercase.\n> + * E.g., `core.ignorecase`, `diff.SomeType.textconv`.\n> + *\n> + * - the value of the variable, as a string. If value is equal to NULL, it will\n> + * remove the matching key from the config file.\n> + *\n> + * - the value regex, as a string. It will disregard key/value pairs where value\n> + * does not match.\n> + *\n> + * - a multi_replace value, as an int. If value is equal to zero, nothing or only\n> + * one matching key/value is replaced, else all matching key/values (regardless\n> + * how many) are removed, before the new pair is written.\n> + *\n> + * It returns 0 on success.\n> + */\n> void git_config_set_multivar_in_file(const char *, const char *, const char *, const char *, int);\n> +\n> +/**\n> + * rename or remove sections in the config file\n> + * parameters `old_name` and `new_name`\n> + * If NULL is passed through `new_name` parameter,\n> + * the section will be removed from the config file.\n> + */\n> int git_config_rename_section(const char *, const char *);\n> int git_config_rename_section_in_file(const char *, const char *, const char *);\n> int git_config_copy_section(const char *, const char *);\n> @@ -142,6 +300,30 @@ enum config_scope current_config_scope(void);\n> const char *current_config_origin_type(void);\n> const char *current_config_name(void);\n> \n> +/**\n> + * Include Directives\n> + * ------------------\n> + *\n> + * By default, the config parser does not respect include directives.\n> + * However, a caller can use the special `git_config_include` wrapper\n> + * callback to support them. To do so, you simply wrap your \"real\" callback\n> + * function and data pointer in a `struct config_include_data`, and pass\n> + * the wrapper to the regular config-reading functions. For example:\n> + *\n> + * -------------------------------------------\n> + * int read_file_with_include(const char *file, config_fn_t fn, void *data)\n> + * {\n> + * struct config_include_data inc = CONFIG_INCLUDE_INIT;\n> + * inc.fn = fn;\n> + * inc.data = data;\n> + * return git_config_from_file(git_config_include, file, &inc);\n> + * }\n> + * -------------------------------------------\n> + *\n> + * `git_config` respects includes automatically. The lower-level\n> + * `git_config_from_file` does not.\n> + *\n> + */\n> struct config_include_data {\n> \tint depth;\n> \tconfig_fn_t fn;\n> @@ -169,6 +351,33 @@ int parse_config_key(const char *var,\n> \t\t const char **subsection, int *subsection_len,\n> \t\t const char **key);\n> \n> +/**\n> + * Custom Configsets\n> + * -----------------\n> + *\n> + * A `config_set` can be used to construct an in-memory cache for\n> + * config-like files that the caller specifies (i.e., files like `.gitmodules`,\n> + * `~/.gitconfig` etc.). For example,\n> + *\n> + * ----------------------------------------\n> + * struct config_set gm_config;\n> + * git_configset_init(&gm_config);\n> + * int b;\n> + * //we add config files to the config_set\n> + * git_configset_add_file(&gm_config, \".gitmodules\");\n> + * git_configset_add_file(&gm_config, \".gitmodules_alt\");\n> + *\n> + * if (!git_configset_get_bool(gm_config, \"submodule.frotz.ignore\", &b)) {\n> + * //hack hack hack\n> + * }\n> + *\n> + * when we are done with the configset:\n> + * git_configset_clear(&gm_config);\n> + * ----------------------------------------\n> + *\n> + * Configset API provides functions for the above mentioned work flow\n> + */\n> +\n> struct config_set_element {\n> \tstruct hashmap_entry ent;\n> \tchar *key;\n> @@ -197,15 +406,45 @@ struct config_set {\n> \tstruct configset_list list;\n> };\n> \n> +/**\n> + * Initializes the config_set `cs`.\n> + */\n> void git_configset_init(struct config_set *cs);\n> +\n> +/**\n> + * Parses the file and adds the variable-value pairs to the `config_set`,\n> + * dies if there is an error in parsing the file. Returns 0 on success, or\n> + * -1 if the file does not exist or is inaccessible. The user has to decide\n> + * if he wants to free the incomplete configset or continue using it when\n> + * the function returns -1.\n> + */\n> int git_configset_add_file(struct config_set *cs, const char *filename);\n> +\n> +/**\n> + * Finds and returns the value list, sorted in order of increasing priority\n> + * for the configuration variable `key` and config set `cs`. When the\n> + * configuration variable `key` is not found, returns NULL. The caller\n> + * should not free or modify the returned pointer, as it is owned by the cache.\n> + */\n> const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key);\n> +\n> +/**\n> + * Clears `config_set` structure, removes all saved variable-value pairs.\n> + */\n> void git_configset_clear(struct config_set *cs);\n> \n> /*\n> * These functions return 1 if not found, and 0 if found, leaving the found\n> * value in the 'dest' pointer.\n> */\n> +\n> +/*\n> + * Finds the highest-priority value for the configuration variable `key`\n> + * and config set `cs`, stores the pointer to it in `value` and returns 0.\n> + * When the configuration variable `key` is not found, returns 1 without\n> + * touching `value`. The caller should not free or modify `value`, as it\n> + * is owned by the cache.\n> + */\n> int git_configset_get_value(struct config_set *cs, const char *key, const char **dest);\n> int git_configset_get_string_const(struct config_set *cs, const char *key, const char **dest);\n> int git_configset_get_string(struct config_set *cs, const char *key, char **dest);\n> @@ -240,16 +479,92 @@ int repo_config_get_maybe_bool(struct repository *repo,\n> int repo_config_get_pathname(struct repository *repo,\n> \t\t\t const char *key, const char **dest);\n> \n> +/**\n> + * Querying For Specific Variables\n> + * -------------------------------\n> + *\n> + * For programs wanting to query for specific variables in a non-callback\n> + * manner, the config API provides two functions `git_config_get_value`\n> + * and `git_config_get_value_multi`. They both read values from an internal\n> + * cache generated previously from reading the config files.\n> + */\n> +\n> +/**\n> + * Finds the highest-priority value for the configuration variable `key`,\n> + * stores the pointer to it in `value` and returns 0. When the\n> + * configuration variable `key` is not found, returns 1 without touching\n> + * `value`. The caller should not free or modify `value`, as it is owned\n> + * by the cache.\n> + */\n> int git_config_get_value(const char *key, const char **value);\n> +\n> +/**\n> + * Finds and returns the value list, sorted in order of increasing priority\n> + * for the configuration variable `key`. When the configuration variable\n> + * `key` is not found, returns NULL. The caller should not free or modify\n> + * the returned pointer, as it is owned by the cache.\n> + */\n> const struct string_list *git_config_get_value_multi(const char *key);\n> +\n> +/**\n> + * Resets and invalidates the config cache.\n> + */\n> void git_config_clear(void);\n> +\n> +/**\n> + * Allocates and copies the retrieved string into the `dest` parameter for\n> + * the configuration variable `key`; if NULL string is given, prints an\n> + * error message and returns -1. When the configuration variable `key` is\n> + * not found, returns 1 without touching `dest`.\n> + */\n> int git_config_get_string_const(const char *key, const char **dest);\n> +\n> +/**\n> + * Similar to `git_config_get_string_const`, except that retrieved value\n> + * copied into the `dest` parameter is a mutable string.\n> + */\n> int git_config_get_string(const char *key, char **dest);\n> +\n> +/**\n> + * Finds and parses the value to an integer for the configuration variable\n> + * `key`. Dies on error; otherwise, stores the value of the parsed integer in\n> + * `dest` and returns 0. When the configuration variable `key` is not found,\n> + * returns 1 without touching `dest`.\n> + */\n> int git_config_get_int(const char *key, int *dest);\n> +\n> +/**\n> + * Similar to `git_config_get_int` but for unsigned longs.\n> + */\n> int git_config_get_ulong(const char *key, unsigned long *dest);\n> +\n> +/**\n> + * Finds and parses the value into a boolean value, for the configuration\n> + * variable `key` respecting keywords like \"true\" and \"false\". Integer\n> + * values are converted into true/false values (when they are non-zero or\n> + * zero, respectively). Other values cause a die(). If parsing is successful,\n> + * stores the value of the parsed result in `dest` and returns 0. When the\n> + * configuration variable `key` is not found, returns 1 without touching\n> + * `dest`.\n> + */\n> int git_config_get_bool(const char *key, int *dest);\n> +\n> +/**\n> + * Similar to `git_config_get_bool`, except that integers are copied as-is,\n> + * and `is_bool` flag is unset.\n> + */\n> int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest);\n> +\n> +/**\n> + * Similar to `git_config_get_bool`, except that it returns -1 on error\n> + * rather than dying.\n> + */\n> int git_config_get_maybe_bool(const char *key, int *dest);\n> +\n> +/**\n> + * Similar to `git_config_get_string`, but expands `~` or `~user` into\n> + * the user's home directory when found at the beginning of the path.\n> + */\n> int git_config_get_pathname(const char *key, const char **dest);\n> int git_config_get_index_threads(int *dest);\n> int git_config_get_untracked_cache(void);\n> @@ -270,7 +585,19 @@ struct key_value_info {\n> \tenum config_scope scope;\n> };\n> \n> +/**\n> + * First prints the error message specified by the caller in `err` and then\n> + * dies printing the line number and the file name of the highest priority\n> + * value for the configuration variable `key`.\n> + */\n> NORETURN void git_die_config(const char *key, const char *err, ...) __attribute__((format(printf, 2, 3)));\n> +\n> +/**\n> + * Helper function which formats the die error message according to the\n> + * parameters entered. Used by `git_die_config()`. It can be used by callers\n> + * handling `git_config_get_value_multi()` to print the correct error message\n> + * for the desired value.\n> + */\n> NORETURN void git_die_config_linenr(const char *key, const char *filename, int linenr);\n> \n> #define LOOKUP_CONFIG(mapping, var) \\\n> -- \n> gitgitgadget\n\nI made a couple of smallish comments about general formatting, but I'm\nalso interested to know whether you were able to move the entire\ncontents of api-config.txt across to here. Was there anything that you\ncouldn't find a place for?\n\nThanks a lot for this change, and congrats on getting your first review\nout! Welcome! :)\n\n - Emily\n\n"},{"id":"384470","messageId":"CACg5j25HsQwjjruHJ2E7F6UF4jP70x436km8r52qpzNSHXfpbA@mail.gmail.com","threadId":"52062","inReplyTo":"20191018220705.241778-1-jonathantanmy@google.com","subject":"Re: [PATCH 1/1] config: add documentation to config.h","fromName":"Heba Waly","fromEmail":"heba.waly@gmail.com","sentAt":"2019-10-20T08:05:27Z","receivedAt":"2019-10-20T08:05:42Z","isPatch":true,"sender":{"key":"heba.waly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1539076?v=4"},"body":"On Sat, Oct 19, 2019 at 11:07 AM Jonathan Tan wrote:\n>\n> > From: Heba Waly \n> >\n> > This commit is copying and summarizing the documentation from\n> > documentation/technical/api-config.txt to comments in config.h\n>\n> Thanks for this commit!\n>\n> As for your commit message, as far as I know, the idea is to move the\n> documentation, not to copy it. Also, write this in imperative form,\n> e.g.:\n>\n> Move the documentation from Documentation/technical/api-config.txt\n> into config.h.\n>\n> Also change the title of the commit message accordingly, e.g.:\n>\n> config: move documentation to header file\n>\nOk.\n> Also, include the deletion of api-config.txt in this commit.\nI wasn't sure if the api-config.txt should be removed or not so I\ndecided to keep it\nand wait for feedback. I assume I'll need to delete api-config.html as well?\n\n> If you are doing any summarizing, describe what summarizing you are\n> doing in the commit message too.\nOk, will do so.\n\n> > + * A config callback function takes three parameters:\n> > + *\n> > + * - the name of the parsed variable. This is in canonical \"flat\" form: the\n> > + * section, subsection, and variable segments will be separated by dots,\n> > + * and the section and variable segments will be all lowercase. E.g.,\n> > + * `core.ignorecase`, `diff.SomeType.textconv`.\n> > + *\n> > + * - the value of the found variable, as a string. If the variable had no\n> > + * value specified, the value will be NULL (typically this means it\n> > + * should be interpreted as boolean true).\n> > + *\n> > + * - a void pointer passed in by the caller of the config API; this can\n> > + * contain callback-specific data\n> > + *\n> > + * A config callback should return 0 for success, or -1 if the variable\n> > + * could not be parsed properly.\n> > + */\n> > +\n> > struct object_id;\n> >\n> > /* git_config_parse_key() returns these negated: */\n> > @@ -73,6 +107,11 @@ struct config_options {\n> >\n> > typedef int (*config_fn_t)(const char *, const char *, void *);\n> > int git_default_config(const char *, const char *, void *);\n>\n> The config callback is config_fn_t so that documentation should be\n> placed above that typedef.\n>\nCool, I couldn't find it, thanks!\n\n> Other than that, this looks good to me. The result is perhaps not as\n> tidy as we would like (especially with some functions being documented\n> and others not) but I think, anyway, that a verbatim movement should be\n> done in one commit (this one) and improvements, in a subsequent commit.\nYou're right, I would have loved to get all the functions documented, but that's\nsomething I'm not able to do right now as I'm still getting familiar\nwith the code base.\nBut it's a good start!\nI agree with you about moving the documentation and deleting the file\nin one commit.\nWill do so.\n\nThank you for the feedback!\n\nHeba\n"},{"id":"384471","messageId":"CACg5j26DuAUm9WR9-4awF7BeGCy81d5kMhhcsePyp3Kxh2DTGg@mail.gmail.com","threadId":"52062","inReplyTo":"20191018225155.GA9323@google.com","subject":"Re: [PATCH 1/1] config: add documentation to config.h","fromName":"Heba Waly","fromEmail":"heba.waly@gmail.com","sentAt":"2019-10-20T08:35:17Z","receivedAt":"2019-10-20T08:35:34Z","isPatch":true,"sender":{"key":"heba.waly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1539076?v=4"},"body":"On Sat, Oct 19, 2019 at 11:52 AM Emily Shaffer wrote:\n>\n> On Fri, Oct 18, 2019 at 12:06:59AM +0000, Heba Waly via GitGitGadget wrote:\n> > From: Heba Waly \n>\n> Hi Heba,\n>\n> Thanks for the patch!\n>\n> I'd like to highlight to the community that this is an Outreachy\n> applicant and microproject. Heba, when you send the next version, I\n> think you can add [Outreachy] manually to the PR subject line - that\n> should draw the attention of those in the community who are invested in\n> helping Outreachy applicants.\nGood idea! I wanted to add it to the email subject but as I decided to\nuse gitgadget\nI had no control over the subject.\n> >\n> > This commit is copying and summarizing the documentation from\n> > documentation/technical/api-config.txt to comments in config.h\n>\n> I think in the GitGitGadget PR you've got some great comments from Dscho\n> about how to format your commit message; please take a look at those and\n> feel free to reach out to me if you're still not sure what's missing or\n> not.\nWill do.\n> > Signed-off-by: Heba Waly \n>\n> One thing I miss in this change is the removal of the contents of\n> Documentation/technical/api-config.txt (or maybe the removal of the file\n> itself). I'd prefer to see at least for api-config.txt to say something\n> like \"Please refer to comments in 'config.h'\"; or, more drastically, for\n> api-config.txt to be removed entirely.\n>\n> Having both pieces of documentation standing independently means that\n> someone who's trying to add new information about the config API won't\n> know where to add it; eventually they'll add something to config.h but\n> not api-config.txt, or vice versa, and the two documents will go out of\n> sync. So we want to move the documentation, rather than copy it.\nThat makes sense, thanks for the explanation.\nI wasn't sure if it should be removed or not so I decided to leave it\nuntil I'm asked otherwise.\nSo I assume api-config.html will be removed too?\n> Plus, having the removed doc as part of this change means I can more\n> easily look at where the lines of content are coming from and see if you\n> made any significant changes from the old contents of api-config.txt.\n> Having a smaller amount of change to review means your review will be\n> quicker - I don't feel as strong a need to check the grammar, spelling,\n> etc, because that text has already been reviewed before, and can just\n> make sure that the placement of each piece of documentation makes sense.\nyes!\n>\n> > ---\n> > config.h | 327 +++++++++++++++++++++++++++++++++++++++++++++++++++++++\n> > 1 file changed, 327 insertions(+)\n> >\n> > diff --git a/config.h b/config.h\n> > index f0ed464004..fa999a2ba0 100644\n> > --- a/config.h\n> > +++ b/config.h\n> > @@ -4,6 +4,40 @@\n> > #include \"hashmap.h\"\n> > #include \"string-list.h\"\n> >\n> > +\n> > +/**\n> > + * The config API gives callers a way to access Git configuration files\n> > + * (and files which have the same syntax). See linkgit:git-config[1] for a\n> > + * discussion of the config file syntax.\n> > + *\n> > + * General Usage\n> > + * -------------\n> > + *\n> > + * Config files are parsed linearly, and each variable found is passed to a\n> > + * caller-provided callback function. The callback function is responsible\n> > + * for any actions to be taken on the config option, and is free to ignore\n> > + * some options. It is not uncommon for the configuration to be parsed\n> > + * several times during the run of a Git program, with different callbacks\n> > + * picking out different variables useful to themselves.\n> > + *\n> > + * A config callback function takes three parameters:\n> > + *\n> > + * - the name of the parsed variable. This is in canonical \"flat\" form: the\n> > + * section, subsection, and variable segments will be separated by dots,\n> > + * and the section and variable segments will be all lowercase. E.g.,\n> > + * `core.ignorecase`, `diff.SomeType.textconv`.\n> > + *\n> > + * - the value of the found variable, as a string. If the variable had no\n> > + * value specified, the value will be NULL (typically this means it\n> > + * should be interpreted as boolean true).\n> > + *\n> > + * - a void pointer passed in by the caller of the config API; this can\n> > + * contain callback-specific data\n> > + *\n> > + * A config callback should return 0 for success, or -1 if the variable\n> > + * could not be parsed properly.\n> > + */\n> > +\n> > struct object_id;\n> >\n> > /* git_config_parse_key() returns these negated: */\n> > @@ -73,6 +107,11 @@ struct config_options {\n> >\n> > typedef int (*config_fn_t)(const char *, const char *, void *);\n> > int git_default_config(const char *, const char *, void *);\n> > +\n> > +/**\n> > + * Read a specific file in git-config format.\n> > + * This function takes the same callback and data parameters as `git_config`.\n> > + */\n> > int git_config_from_file(config_fn_t fn, const char *, void *);\n> > int git_config_from_file_with_options(config_fn_t fn, const char *,\n> > void *,\n> > @@ -88,33 +127,152 @@ void git_config_push_parameter(const char *text);\n> > int git_config_from_parameters(config_fn_t fn, void *data);\n> > void read_early_config(config_fn_t cb, void *data);\n> > void read_very_early_config(config_fn_t cb, void *data);\n> > +\n> > +/**\n> > + * Most programs will simply want to look up variables in all config files\n> > + * that Git knows about, using the normal precedence rules. To do this,\n> > + * call `git_config` with a callback function and void data pointer.\n> > + *\n> > + * `git_config` will read all config sources in order of increasing\n> > + * priority. Thus a callback should typically overwrite previously-seen\n> > + * entries with new ones (e.g., if both the user-wide `~/.gitconfig` and\n> > + * repo-specific `.git/config` contain `color.ui`, the config machinery\n> > + * will first feed the user-wide one to the callback, and then the\n> > + * repo-specific one; by overwriting, the higher-priority repo-specific\n> > + * value is left at the end).\n> > + */\n> > void git_config(config_fn_t fn, void *);\n> > +\n> > +/**\n> > + * Lets the caller examine config while adjusting some of the default\n> > + * behavior of `git_config`. It should almost never be used by \"regular\"\n> > + * Git code that is looking up configuration variables.\n> > + * It is intended for advanced callers like `git-config`, which are\n> > + * intentionally tweaking the normal config-lookup process.\n> > + * It takes two extra parameters:\n> > + *\n> > + * `config_source`::\n>\n> I think the wonky trailing \"::\" is for generating manpages/HTML out of\n> the asciidoc from the original api-config.txt. I expect it's OK to\n> remove them throughout this change and format this in a way that makes more\n> sense for comments which won't be converted into anything else.\nGood catch! thanks, will change that.\n\n> > + * If this parameter is non-NULL, it specifies the source to parse for\n> > + * configuration, rather than looking in the usual files. See `struct\n> > + * git_config_source` in `config.h` for details. Regular `git_config` defaults\n> > + * to `NULL`.\n> > + *\n> > + * `opts`::\n> > + * Specify options to adjust the behavior of parsing config files. See `struct\n> > + * config_options` in `config.h` for details. As an example: regular `git_config`\n> > + * sets `opts.respect_includes` to `1` by default.\n> > + */\n> > int config_with_options(config_fn_t fn, void *,\n> > struct git_config_source *config_source,\n> > const struct config_options *opts);\n> > +\n> > +/**\n> > + * Value Parsing Helpers\n> > + * ---------------------\n>\n> It may not make sense to have the header here in the middle of the doc.\n>\n> I wonder whether we need the headers at all anymore; or, whether it\n> makes more sense to put this header in the long comment at the top with\n> just the list of function names (so someone knows where to look), and\n> leave the per-function explanations inline with the function they\n> describe?\nI see your point Emily, but in the CodingGuidelines file it was\nadvised to refer to strbuf.h\nas a model for documentation, I noticed that strbuf.h used headers\nthis way so I decided\nto replicate that.\n> > + *\n> > + * To aid in parsing string values, the config API provides callbacks with\n> > + * a number of helper functions\n>\n> In the copy paste, this lost some ending punctuation. I'd advocate\n> ending this with \":\" to indicate \"we are about to give the list of those\n> functions\". Although, I wonder whether it makes more sense to rephrase\n> this into something like \"The following helper functions aid in parsing\n> string values:\"? Not sure.\nI like that. will rephrase it.\n> > + */\n> > +\n> > int git_parse_ssize_t(const char *, ssize_t *);\n> > int git_parse_ulong(const char *, unsigned long *);\n> > +\n> > +/**\n> > + * Same as `git_config_bool`, except that it returns -1 on error rather\n> > + * than dying.\n> > + */\n> > int git_parse_maybe_bool(const char *);\n> > +\n> > +/**\n> > + * Parse the string to an integer, including unit factors. Dies on error;\n> > + * otherwise, returns the parsed result.\n> > + */\n> > int git_config_int(const char *, const char *);\n> > int64_t git_config_int64(const char *, const char *);\n> > +\n> > +/**\n> > + * Identical to `git_config_int`, but for unsigned longs.\n> > + */\n> > unsigned long git_config_ulong(const char *, const char *);\n> > ssize_t git_config_ssize_t(const char *, const char *);\n> > +\n> > +/**\n> > + * Same as `git_config_bool`, except that integers are returned as-is, and\n> > + * an `is_bool` flag is unset.\n> > + */\n> > int git_config_bool_or_int(const char *, const char *, int *);\n> > +\n> > +/**\n> > + * Parse a string into a boolean value, respecting keywords like \"true\" and\n> > + * \"false\". Integer values are converted into true/false values (when they\n> > + * are non-zero or zero, respectively). Other values cause a die(). If\n> > + * parsing is successful, the return value is the result.\n> > + */\n> > int git_config_bool(const char *, const char *);\n> > +\n> > +/**\n> > + * Allocates and copies the value string into the `dest` parameter; if no\n> > + * string is given, prints an error message and returns -1.\n> > + */\n> > int git_config_string(const char **, const char *, const char *);\n> > +\n> > +/**\n> > + * Similar to `git_config_string`, but expands `~` or `~user` into the\n> > + * user's home directory when found at the beginning of the path.\n> > + */\n> > int git_config_pathname(const char **, const char *, const char *);\n>\n> I might like to see another space under this function so it's clear\n> that the description isn't talking about expiry, color, or\n> set_in_file_gently. There are other places where this comment applies,\n> too.\nYes.\n> > int git_config_expiry_date(timestamp_t *, const char *, const char *);\n> > int git_config_color(char *, const char *, const char *);\n> > int git_config_set_in_file_gently(const char *, const char *, const char *);\n> > +\n> > +/**\n> > + * write config values to a specific config file\n> > + * takes a key/value pair as parameter.\n> > + */\n>\n> You could reflow this comment and some others so that they extend closer\n> to the end of the 80c line width; in some cases you can condense the\n> comment to a single line this way :)\nOk.\n> > void git_config_set_in_file(const char *, const char *, const char *);\n> > int git_config_set_gently(const char *, const char *);\n> > +\n> > +/**\n> > + * write config values to `.git/config`\n> > + * takes a key/value pair as parameter.\n> > + */\n> > void git_config_set(const char *, const char *);\n> > int git_config_parse_key(const char *, char **, int *);\n> > int git_config_key_is_valid(const char *key);\n> > int git_config_set_multivar_gently(const char *, const char *, const char *, int);\n> > void git_config_set_multivar(const char *, const char *, const char *, int);\n> > int git_config_set_multivar_in_file_gently(const char *, const char *, const char *, const char *, int);\n> > +\n> > +/**\n> > + * takes four parameters:\n> > + *\n> > + * - the name of the file, as a string, to which key/value pairs will be written.\n> > + *\n> > + * - the name of key, as a string. This is in canonical \"flat\" form: the section,\n> > + * subsection, and variable segments will be separated by dots, and the section\n> > + * and variable segments will be all lowercase.\n> > + * E.g., `core.ignorecase`, `diff.SomeType.textconv`.\n> > + *\n> > + * - the value of the variable, as a string. If value is equal to NULL, it will\n> > + * remove the matching key from the config file.\n> > + *\n> > + * - the value regex, as a string. It will disregard key/value pairs where value\n> > + * does not match.\n> > + *\n> > + * - a multi_replace value, as an int. If value is equal to zero, nothing or only\n> > + * one matching key/value is replaced, else all matching key/values (regardless\n> > + * how many) are removed, before the new pair is written.\n> > + *\n> > + * It returns 0 on success.\n> > + */\n> > void git_config_set_multivar_in_file(const char *, const char *, const char *, const char *, int);\n> > +\n> > +/**\n> > + * rename or remove sections in the config file\n> > + * parameters `old_name` and `new_name`\n> > + * If NULL is passed through `new_name` parameter,\n> > + * the section will be removed from the config file.\n> > + */\n> > int git_config_rename_section(const char *, const char *);\n> > int git_config_rename_section_in_file(const char *, const char *, const char *);\n> > int git_config_copy_section(const char *, const char *);\n> > @@ -142,6 +300,30 @@ enum config_scope current_config_scope(void);\n> > const char *current_config_origin_type(void);\n> > const char *current_config_name(void);\n> >\n> > +/**\n> > + * Include Directives\n> > + * ------------------\n> > + *\n> > + * By default, the config parser does not respect include directives.\n> > + * However, a caller can use the special `git_config_include` wrapper\n> > + * callback to support them. To do so, you simply wrap your \"real\" callback\n> > + * function and data pointer in a `struct config_include_data`, and pass\n> > + * the wrapper to the regular config-reading functions. For example:\n> > + *\n> > + * -------------------------------------------\n> > + * int read_file_with_include(const char *file, config_fn_t fn, void *data)\n> > + * {\n> > + * struct config_include_data inc = CONFIG_INCLUDE_INIT;\n> > + * inc.fn = fn;\n> > + * inc.data = data;\n> > + * return git_config_from_file(git_config_include, file, &inc);\n> > + * }\n> > + * -------------------------------------------\n> > + *\n> > + * `git_config` respects includes automatically. The lower-level\n> > + * `git_config_from_file` does not.\n> > + *\n> > + */\n> > struct config_include_data {\n> > int depth;\n> > config_fn_t fn;\n> > @@ -169,6 +351,33 @@ int parse_config_key(const char *var,\n> > const char **subsection, int *subsection_len,\n> > const char **key);\n> >\n> > +/**\n> > + * Custom Configsets\n> > + * -----------------\n> > + *\n> > + * A `config_set` can be used to construct an in-memory cache for\n> > + * config-like files that the caller specifies (i.e., files like `.gitmodules`,\n> > + * `~/.gitconfig` etc.). For example,\n> > + *\n> > + * ----------------------------------------\n> > + * struct config_set gm_config;\n> > + * git_configset_init(&gm_config);\n> > + * int b;\n> > + * //we add config files to the config_set\n> > + * git_configset_add_file(&gm_config, \".gitmodules\");\n> > + * git_configset_add_file(&gm_config, \".gitmodules_alt\");\n> > + *\n> > + * if (!git_configset_get_bool(gm_config, \"submodule.frotz.ignore\", &b)) {\n> > + * //hack hack hack\n> > + * }\n> > + *\n> > + * when we are done with the configset:\n> > + * git_configset_clear(&gm_config);\n> > + * ----------------------------------------\n> > + *\n> > + * Configset API provides functions for the above mentioned work flow\n> > + */\n> > +\n> > struct config_set_element {\n> > struct hashmap_entry ent;\n> > char *key;\n> > @@ -197,15 +406,45 @@ struct config_set {\n> > struct configset_list list;\n> > };\n> >\n> > +/**\n> > + * Initializes the config_set `cs`.\n> > + */\n> > void git_configset_init(struct config_set *cs);\n> > +\n> > +/**\n> > + * Parses the file and adds the variable-value pairs to the `config_set`,\n> > + * dies if there is an error in parsing the file. Returns 0 on success, or\n> > + * -1 if the file does not exist or is inaccessible. The user has to decide\n> > + * if he wants to free the incomplete configset or continue using it when\n> > + * the function returns -1.\n> > + */\n> > int git_configset_add_file(struct config_set *cs, const char *filename);\n> > +\n> > +/**\n> > + * Finds and returns the value list, sorted in order of increasing priority\n> > + * for the configuration variable `key` and config set `cs`. When the\n> > + * configuration variable `key` is not found, returns NULL. The caller\n> > + * should not free or modify the returned pointer, as it is owned by the cache.\n> > + */\n> > const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key);\n> > +\n> > +/**\n> > + * Clears `config_set` structure, removes all saved variable-value pairs.\n> > + */\n> > void git_configset_clear(struct config_set *cs);\n> >\n> > /*\n> > * These functions return 1 if not found, and 0 if found, leaving the found\n> > * value in the 'dest' pointer.\n> > */\n> > +\n> > +/*\n> > + * Finds the highest-priority value for the configuration variable `key`\n> > + * and config set `cs`, stores the pointer to it in `value` and returns 0.\n> > + * When the configuration variable `key` is not found, returns 1 without\n> > + * touching `value`. The caller should not free or modify `value`, as it\n> > + * is owned by the cache.\n> > + */\n> > int git_configset_get_value(struct config_set *cs, const char *key, const char **dest);\n> > int git_configset_get_string_const(struct config_set *cs, const char *key, const char **dest);\n> > int git_configset_get_string(struct config_set *cs, const char *key, char **dest);\n> > @@ -240,16 +479,92 @@ int repo_config_get_maybe_bool(struct repository *repo,\n> > int repo_config_get_pathname(struct repository *repo,\n> > const char *key, const char **dest);\n> >\n> > +/**\n> > + * Querying For Specific Variables\n> > + * -------------------------------\n> > + *\n> > + * For programs wanting to query for specific variables in a non-callback\n> > + * manner, the config API provides two functions `git_config_get_value`\n> > + * and `git_config_get_value_multi`. They both read values from an internal\n> > + * cache generated previously from reading the config files.\n> > + */\n> > +\n> > +/**\n> > + * Finds the highest-priority value for the configuration variable `key`,\n> > + * stores the pointer to it in `value` and returns 0. When the\n> > + * configuration variable `key` is not found, returns 1 without touching\n> > + * `value`. The caller should not free or modify `value`, as it is owned\n> > + * by the cache.\n> > + */\n> > int git_config_get_value(const char *key, const char **value);\n> > +\n> > +/**\n> > + * Finds and returns the value list, sorted in order of increasing priority\n> > + * for the configuration variable `key`. When the configuration variable\n> > + * `key` is not found, returns NULL. The caller should not free or modify\n> > + * the returned pointer, as it is owned by the cache.\n> > + */\n> > const struct string_list *git_config_get_value_multi(const char *key);\n> > +\n> > +/**\n> > + * Resets and invalidates the config cache.\n> > + */\n> > void git_config_clear(void);\n> > +\n> > +/**\n> > + * Allocates and copies the retrieved string into the `dest` parameter for\n> > + * the configuration variable `key`; if NULL string is given, prints an\n> > + * error message and returns -1. When the configuration variable `key` is\n> > + * not found, returns 1 without touching `dest`.\n> > + */\n> > int git_config_get_string_const(const char *key, const char **dest);\n> > +\n> > +/**\n> > + * Similar to `git_config_get_string_const`, except that retrieved value\n> > + * copied into the `dest` parameter is a mutable string.\n> > + */\n> > int git_config_get_string(const char *key, char **dest);\n> > +\n> > +/**\n> > + * Finds and parses the value to an integer for the configuration variable\n> > + * `key`. Dies on error; otherwise, stores the value of the parsed integer in\n> > + * `dest` and returns 0. When the configuration variable `key` is not found,\n> > + * returns 1 without touching `dest`.\n> > + */\n> > int git_config_get_int(const char *key, int *dest);\n> > +\n> > +/**\n> > + * Similar to `git_config_get_int` but for unsigned longs.\n> > + */\n> > int git_config_get_ulong(const char *key, unsigned long *dest);\n> > +\n> > +/**\n> > + * Finds and parses the value into a boolean value, for the configuration\n> > + * variable `key` respecting keywords like \"true\" and \"false\". Integer\n> > + * values are converted into true/false values (when they are non-zero or\n> > + * zero, respectively). Other values cause a die(). If parsing is successful,\n> > + * stores the value of the parsed result in `dest` and returns 0. When the\n> > + * configuration variable `key` is not found, returns 1 without touching\n> > + * `dest`.\n> > + */\n> > int git_config_get_bool(const char *key, int *dest);\n> > +\n> > +/**\n> > + * Similar to `git_config_get_bool`, except that integers are copied as-is,\n> > + * and `is_bool` flag is unset.\n> > + */\n> > int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest);\n> > +\n> > +/**\n> > + * Similar to `git_config_get_bool`, except that it returns -1 on error\n> > + * rather than dying.\n> > + */\n> > int git_config_get_maybe_bool(const char *key, int *dest);\n> > +\n> > +/**\n> > + * Similar to `git_config_get_string`, but expands `~` or `~user` into\n> > + * the user's home directory when found at the beginning of the path.\n> > + */\n> > int git_config_get_pathname(const char *key, const char **dest);\n> > int git_config_get_index_threads(int *dest);\n> > int git_config_get_untracked_cache(void);\n> > @@ -270,7 +585,19 @@ struct key_value_info {\n> > enum config_scope scope;\n> > };\n> >\n> > +/**\n> > + * First prints the error message specified by the caller in `err` and then\n> > + * dies printing the line number and the file name of the highest priority\n> > + * value for the configuration variable `key`.\n> > + */\n> > NORETURN void git_die_config(const char *key, const char *err, ...) __attribute__((format(printf, 2, 3)));\n> > +\n> > +/**\n> > + * Helper function which formats the die error message according to the\n> > + * parameters entered. Used by `git_die_config()`. It can be used by callers\n> > + * handling `git_config_get_value_multi()` to print the correct error message\n> > + * for the desired value.\n> > + */\n> > NORETURN void git_die_config_linenr(const char *key, const char *filename, int linenr);\n> >\n> > #define LOOKUP_CONFIG(mapping, var) \\\n> > --\n> > gitgitgadget\n>\n> I made a couple of smallish comments about general formatting, but I'm\n> also interested to know whether you were able to move the entire\n> contents of api-config.txt across to here. Was there anything that you\n> couldn't find a place for?\nYes, everything is moved.\n> Thanks a lot for this change, and congrats on getting your first review\n> out! Welcome! :)\n>\n> - Emily\n>\nThanks a lot Emily for the detailed and helpful feedback!\n\nHeba\n"},{"id":"384573","messageId":"pull.405.v2.git.1571727906.gitgitgadget@gmail.com","threadId":"52062","inReplyTo":"pull.405.git.1571357219.gitgitgadget@gmail.com","subject":"[PATCH v2 0/1] [Outreachy] config: move documentation to config.h","fromName":"Heba Waly via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-10-22T07:05:05Z","receivedAt":"2019-10-22T07:05:13Z","isPatch":true,"sender":{"key":"heba.waly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1539076?v=4"},"body":"Move the documentation from Documentation/technical/api-config.txt into\nconfig.h\n\nSigned-off-by: Heba Waly heba.waly@gmail.com [heba.waly@gmail.com]\n\nThanks for taking the time to contribute to Git! Please be advised that the\nGit community does not use github.com for their contributions. Instead, we\nuse a mailing list (git@vger.kernel.org) for code submissions, code reviews,\nand bug reports. Nevertheless, you can use GitGitGadget (\nhttps://gitgitgadget.github.io/) to conveniently send your Pull Requests\ncommits to our mailing list.\n\nPlease read the \"guidelines for contributing\" linked above!\n\nHeba Waly (1):\n config: move documentation to config.h\n\n Documentation/technical/api-config.txt | 319 -----------------------\n config.h | 336 +++++++++++++++++++++++++\n 2 files changed, 336 insertions(+), 319 deletions(-)\n delete mode 100644 Documentation/technical/api-config.txt\n\n\nbase-commit: 108b97dc372828f0e72e56bbb40cae8e1e83ece6\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-405%2FHebaWaly%2Fconfig_documentation-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-405/HebaWaly/config_documentation-v2\nPull-Request: https://github.com/gitgitgadget/git/pull/405\n\nRange-diff vs v1:\n\n 1: 2e42eafb5d ! 1: 1a9aa33b46 config: add documentation to config.h\n @@ -1,12 +1,336 @@\n Author: Heba Waly \n \n - config: add documentation to config.h\n -\n - This commit is copying and summarizing the documentation from\n - documentation/technical/api-config.txt to comments in config.h\n + config: move documentation to config.h\n \n + Move the documentation from Documentation/technical/api-config.txt into\n + config.h\n Signed-off-by: Heba Waly \n \n + diff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt\n + deleted file mode 100644\n + --- a/Documentation/technical/api-config.txt\n + +++ /dev/null\n +@@\n +-config API\n +-==========\n +-\n +-The config API gives callers a way to access Git configuration files\n +-(and files which have the same syntax). See linkgit:git-config[1] for a\n +-discussion of the config file syntax.\n +-\n +-General Usage\n +--------------\n +-\n +-Config files are parsed linearly, and each variable found is passed to a\n +-caller-provided callback function. The callback function is responsible\n +-for any actions to be taken on the config option, and is free to ignore\n +-some options. It is not uncommon for the configuration to be parsed\n +-several times during the run of a Git program, with different callbacks\n +-picking out different variables useful to themselves.\n +-\n +-A config callback function takes three parameters:\n +-\n +-- the name of the parsed variable. This is in canonical \"flat\" form: the\n +- section, subsection, and variable segments will be separated by dots,\n +- and the section and variable segments will be all lowercase. E.g.,\n +- `core.ignorecase`, `diff.SomeType.textconv`.\n +-\n +-- the value of the found variable, as a string. If the variable had no\n +- value specified, the value will be NULL (typically this means it\n +- should be interpreted as boolean true).\n +-\n +-- a void pointer passed in by the caller of the config API; this can\n +- contain callback-specific data\n +-\n +-A config callback should return 0 for success, or -1 if the variable\n +-could not be parsed properly.\n +-\n +-Basic Config Querying\n +----------------------\n +-\n +-Most programs will simply want to look up variables in all config files\n +-that Git knows about, using the normal precedence rules. To do this,\n +-call `git_config` with a callback function and void data pointer.\n +-\n +-`git_config` will read all config sources in order of increasing\n +-priority. Thus a callback should typically overwrite previously-seen\n +-entries with new ones (e.g., if both the user-wide `~/.gitconfig` and\n +-repo-specific `.git/config` contain `color.ui`, the config machinery\n +-will first feed the user-wide one to the callback, and then the\n +-repo-specific one; by overwriting, the higher-priority repo-specific\n +-value is left at the end).\n +-\n +-The `config_with_options` function lets the caller examine config\n +-while adjusting some of the default behavior of `git_config`. It should\n +-almost never be used by \"regular\" Git code that is looking up\n +-configuration variables. It is intended for advanced callers like\n +-`git-config`, which are intentionally tweaking the normal config-lookup\n +-process. It takes two extra parameters:\n +-\n +-`config_source`::\n +-If this parameter is non-NULL, it specifies the source to parse for\n +-configuration, rather than looking in the usual files. See `struct\n +-git_config_source` in `config.h` for details. Regular `git_config` defaults\n +-to `NULL`.\n +-\n +-`opts`::\n +-Specify options to adjust the behavior of parsing config files. See `struct\n +-config_options` in `config.h` for details. As an example: regular `git_config`\n +-sets `opts.respect_includes` to `1` by default.\n +-\n +-Reading Specific Files\n +-----------------------\n +-\n +-To read a specific file in git-config format, use\n +-`git_config_from_file`. This takes the same callback and data parameters\n +-as `git_config`.\n +-\n +-Querying For Specific Variables\n +--------------------------------\n +-\n +-For programs wanting to query for specific variables in a non-callback\n +-manner, the config API provides two functions `git_config_get_value`\n +-and `git_config_get_value_multi`. They both read values from an internal\n +-cache generated previously from reading the config files.\n +-\n +-`int git_config_get_value(const char *key, const char **value)`::\n +-\n +-\tFinds the highest-priority value for the configuration variable `key`,\n +-\tstores the pointer to it in `value` and returns 0. When the\n +-\tconfiguration variable `key` is not found, returns 1 without touching\n +-\t`value`. The caller should not free or modify `value`, as it is owned\n +-\tby the cache.\n +-\n +-`const struct string_list *git_config_get_value_multi(const char *key)`::\n +-\n +-\tFinds and returns the value list, sorted in order of increasing priority\n +-\tfor the configuration variable `key`. When the configuration variable\n +-\t`key` is not found, returns NULL. The caller should not free or modify\n +-\tthe returned pointer, as it is owned by the cache.\n +-\n +-`void git_config_clear(void)`::\n +-\n +-\tResets and invalidates the config cache.\n +-\n +-The config API also provides type specific API functions which do conversion\n +-as well as retrieval for the queried variable, including:\n +-\n +-`int git_config_get_int(const char *key, int *dest)`::\n +-\n +-\tFinds and parses the value to an integer for the configuration variable\n +-\t`key`. Dies on error; otherwise, stores the value of the parsed integer in\n +-\t`dest` and returns 0. When the configuration variable `key` is not found,\n +-\treturns 1 without touching `dest`.\n +-\n +-`int git_config_get_ulong(const char *key, unsigned long *dest)`::\n +-\n +-\tSimilar to `git_config_get_int` but for unsigned longs.\n +-\n +-`int git_config_get_bool(const char *key, int *dest)`::\n +-\n +-\tFinds and parses the value into a boolean value, for the configuration\n +-\tvariable `key` respecting keywords like \"true\" and \"false\". Integer\n +-\tvalues are converted into true/false values (when they are non-zero or\n +-\tzero, respectively). Other values cause a die(). If parsing is successful,\n +-\tstores the value of the parsed result in `dest` and returns 0. When the\n +-\tconfiguration variable `key` is not found, returns 1 without touching\n +-\t`dest`.\n +-\n +-`int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest)`::\n +-\n +-\tSimilar to `git_config_get_bool`, except that integers are copied as-is,\n +-\tand `is_bool` flag is unset.\n +-\n +-`int git_config_get_maybe_bool(const char *key, int *dest)`::\n +-\n +-\tSimilar to `git_config_get_bool`, except that it returns -1 on error\n +-\trather than dying.\n +-\n +-`int git_config_get_string_const(const char *key, const char **dest)`::\n +-\n +-\tAllocates and copies the retrieved string into the `dest` parameter for\n +-\tthe configuration variable `key`; if NULL string is given, prints an\n +-\terror message and returns -1. When the configuration variable `key` is\n +-\tnot found, returns 1 without touching `dest`.\n +-\n +-`int git_config_get_string(const char *key, char **dest)`::\n +-\n +-\tSimilar to `git_config_get_string_const`, except that retrieved value\n +-\tcopied into the `dest` parameter is a mutable string.\n +-\n +-`int git_config_get_pathname(const char *key, const char **dest)`::\n +-\n +-\tSimilar to `git_config_get_string`, but expands `~` or `~user` into\n +-\tthe user's home directory when found at the beginning of the path.\n +-\n +-`git_die_config(const char *key, const char *err, ...)`::\n +-\n +-\tFirst prints the error message specified by the caller in `err` and then\n +-\tdies printing the line number and the file name of the highest priority\n +-\tvalue for the configuration variable `key`.\n +-\n +-`void git_die_config_linenr(const char *key, const char *filename, int linenr)`::\n +-\n +-\tHelper function which formats the die error message according to the\n +-\tparameters entered. Used by `git_die_config()`. It can be used by callers\n +-\thandling `git_config_get_value_multi()` to print the correct error message\n +-\tfor the desired value.\n +-\n +-See test-config.c for usage examples.\n +-\n +-Value Parsing Helpers\n +----------------------\n +-\n +-To aid in parsing string values, the config API provides callbacks with\n +-a number of helper functions, including:\n +-\n +-`git_config_int`::\n +-Parse the string to an integer, including unit factors. Dies on error;\n +-otherwise, returns the parsed result.\n +-\n +-`git_config_ulong`::\n +-Identical to `git_config_int`, but for unsigned longs.\n +-\n +-`git_config_bool`::\n +-Parse a string into a boolean value, respecting keywords like \"true\" and\n +-\"false\". Integer values are converted into true/false values (when they\n +-are non-zero or zero, respectively). Other values cause a die(). If\n +-parsing is successful, the return value is the result.\n +-\n +-`git_config_bool_or_int`::\n +-Same as `git_config_bool`, except that integers are returned as-is, and\n +-an `is_bool` flag is unset.\n +-\n +-`git_parse_maybe_bool`::\n +-Same as `git_config_bool`, except that it returns -1 on error rather\n +-than dying.\n +-\n +-`git_config_string`::\n +-Allocates and copies the value string into the `dest` parameter; if no\n +-string is given, prints an error message and returns -1.\n +-\n +-`git_config_pathname`::\n +-Similar to `git_config_string`, but expands `~` or `~user` into the\n +-user's home directory when found at the beginning of the path.\n +-\n +-Include Directives\n +-------------------\n +-\n +-By default, the config parser does not respect include directives.\n +-However, a caller can use the special `git_config_include` wrapper\n +-callback to support them. To do so, you simply wrap your \"real\" callback\n +-function and data pointer in a `struct config_include_data`, and pass\n +-the wrapper to the regular config-reading functions. For example:\n +-\n +--------------------------------------------\n +-int read_file_with_include(const char *file, config_fn_t fn, void *data)\n +-{\n +-\tstruct config_include_data inc = CONFIG_INCLUDE_INIT;\n +-\tinc.fn = fn;\n +-\tinc.data = data;\n +-\treturn git_config_from_file(git_config_include, file, &inc);\n +-}\n +--------------------------------------------\n +-\n +-`git_config` respects includes automatically. The lower-level\n +-`git_config_from_file` does not.\n +-\n +-Custom Configsets\n +------------------\n +-\n +-A `config_set` can be used to construct an in-memory cache for\n +-config-like files that the caller specifies (i.e., files like `.gitmodules`,\n +-`~/.gitconfig` etc.). For example,\n +-\n +-----------------------------------------\n +-struct config_set gm_config;\n +-git_configset_init(&gm_config);\n +-int b;\n +-/* we add config files to the config_set */\n +-git_configset_add_file(&gm_config, \".gitmodules\");\n +-git_configset_add_file(&gm_config, \".gitmodules_alt\");\n +-\n +-if (!git_configset_get_bool(gm_config, \"submodule.frotz.ignore\", &b)) {\n +-\t/* hack hack hack */\n +-}\n +-\n +-/* when we are done with the configset */\n +-git_configset_clear(&gm_config);\n +-----------------------------------------\n +-\n +-Configset API provides functions for the above mentioned work flow, including:\n +-\n +-`void git_configset_init(struct config_set *cs)`::\n +-\n +-\tInitializes the config_set `cs`.\n +-\n +-`int git_configset_add_file(struct config_set *cs, const char *filename)`::\n +-\n +-\tParses the file and adds the variable-value pairs to the `config_set`,\n +-\tdies if there is an error in parsing the file. Returns 0 on success, or\n +-\t-1 if the file does not exist or is inaccessible. The user has to decide\n +-\tif he wants to free the incomplete configset or continue using it when\n +-\tthe function returns -1.\n +-\n +-`int git_configset_get_value(struct config_set *cs, const char *key, const char **value)`::\n +-\n +-\tFinds the highest-priority value for the configuration variable `key`\n +-\tand config set `cs`, stores the pointer to it in `value` and returns 0.\n +-\tWhen the configuration variable `key` is not found, returns 1 without\n +-\ttouching `value`. The caller should not free or modify `value`, as it\n +-\tis owned by the cache.\n +-\n +-`const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key)`::\n +-\n +-\tFinds and returns the value list, sorted in order of increasing priority\n +-\tfor the configuration variable `key` and config set `cs`. When the\n +-\tconfiguration variable `key` is not found, returns NULL. The caller\n +-\tshould not free or modify the returned pointer, as it is owned by the cache.\n +-\n +-`void git_configset_clear(struct config_set *cs)`::\n +-\n +-\tClears `config_set` structure, removes all saved variable-value pairs.\n +-\n +-In addition to above functions, the `config_set` API provides type specific\n +-functions in the vein of `git_config_get_int` and family but with an extra\n +-parameter, pointer to struct `config_set`.\n +-They all behave similarly to the `git_config_get*()` family described in\n +-\"Querying For Specific Variables\" above.\n +-\n +-Writing Config Files\n +---------------------\n +-\n +-Git gives multiple entry points in the Config API to write config values to\n +-files namely `git_config_set_in_file` and `git_config_set`, which write to\n +-a specific config file or to `.git/config` respectively. They both take a\n +-key/value pair as parameter.\n +-In the end they both call `git_config_set_multivar_in_file` which takes four\n +-parameters:\n +-\n +-- the name of the file, as a string, to which key/value pairs will be written.\n +-\n +-- the name of key, as a string. This is in canonical \"flat\" form: the section,\n +- subsection, and variable segments will be separated by dots, and the section\n +- and variable segments will be all lowercase.\n +- E.g., `core.ignorecase`, `diff.SomeType.textconv`.\n +-\n +-- the value of the variable, as a string. If value is equal to NULL, it will\n +- remove the matching key from the config file.\n +-\n +-- the value regex, as a string. It will disregard key/value pairs where value\n +- does not match.\n +-\n +-- a multi_replace value, as an int. If value is equal to zero, nothing or only\n +- one matching key/value is replaced, else all matching key/values (regardless\n +- how many) are removed, before the new pair is written.\n +-\n +-It returns 0 on success.\n +-\n +-Also, there are functions `git_config_rename_section` and\n +-`git_config_rename_section_in_file` with parameters `old_name` and `new_name`\n +-for renaming or removing sections in the config files. If NULL is passed\n +-through `new_name` parameter, the section will be removed from the config file.\n +\n diff --git a/config.h b/config.h\n --- a/config.h\n +++ b/config.h\n @@ -29,7 +353,16 @@\n + * some options. It is not uncommon for the configuration to be parsed\n + * several times during the run of a Git program, with different callbacks\n + * picking out different variables useful to themselves.\n -+ *\n ++ */\n ++\n + struct object_id;\n + \n + /* git_config_parse_key() returns these negated: */\n +@@\n + \t} error_action;\n + };\n + \n ++/**\n + * A config callback function takes three parameters:\n + *\n + * - the name of the parsed variable. This is in canonical \"flat\" form: the\n @@ -47,13 +380,8 @@\n + * A config callback should return 0 for success, or -1 if the variable\n + * could not be parsed properly.\n + */\n -+\n - struct object_id;\n - \n - /* git_config_parse_key() returns these negated: */\n -@@\n - \n typedef int (*config_fn_t)(const char *, const char *, void *);\n ++\n int git_default_config(const char *, const char *, void *);\n +\n +/**\n @@ -61,8 +389,10 @@\n + * This function takes the same callback and data parameters as `git_config`.\n + */\n int git_config_from_file(config_fn_t fn, const char *, void *);\n ++\n int git_config_from_file_with_options(config_fn_t fn, const char *,\n \t\t\t\t void *,\n + \t\t\t\t const struct config_options *);\n @@\n int git_config_from_parameters(config_fn_t fn, void *data);\n void read_early_config(config_fn_t cb, void *data);\n @@ -91,13 +421,13 @@\n + * intentionally tweaking the normal config-lookup process.\n + * It takes two extra parameters:\n + *\n -+ * `config_source`::\n ++ * - `config_source`\n + * If this parameter is non-NULL, it specifies the source to parse for\n + * configuration, rather than looking in the usual files. See `struct\n + * git_config_source` in `config.h` for details. Regular `git_config` defaults\n + * to `NULL`.\n + *\n -+ * `opts`::\n ++ * - `opts`\n + * Specify options to adjust the behavior of parsing config files. See `struct\n + * config_options` in `config.h` for details. As an example: regular `git_config`\n + * sets `opts.respect_includes` to `1` by default.\n @@ -110,8 +440,7 @@\n + * Value Parsing Helpers\n + * ---------------------\n + *\n -+ * To aid in parsing string values, the config API provides callbacks with\n -+ * a number of helper functions\n ++ * The following helper functions aid in parsing string values\n + */\n +\n int git_parse_ssize_t(const char *, ssize_t *);\n @@ -128,12 +457,14 @@\n + * otherwise, returns the parsed result.\n + */\n int git_config_int(const char *, const char *);\n ++\n int64_t git_config_int64(const char *, const char *);\n +\n +/**\n + * Identical to `git_config_int`, but for unsigned longs.\n + */\n unsigned long git_config_ulong(const char *, const char *);\n ++\n ssize_t git_config_ssize_t(const char *, const char *);\n +\n +/**\n @@ -161,22 +492,24 @@\n + * user's home directory when found at the beginning of the path.\n + */\n int git_config_pathname(const char **, const char *, const char *);\n ++\n int git_config_expiry_date(timestamp_t *, const char *, const char *);\n int git_config_color(char *, const char *, const char *);\n int git_config_set_in_file_gently(const char *, const char *, const char *);\n +\n +/**\n -+ * write config values to a specific config file\n -+ * takes a key/value pair as parameter.\n ++ * write config values to a specific config file, takes a key/value pair as\n ++ * parameter.\n + */\n void git_config_set_in_file(const char *, const char *, const char *);\n ++\n int git_config_set_gently(const char *, const char *);\n +\n +/**\n -+ * write config values to `.git/config`\n -+ * takes a key/value pair as parameter.\n ++ * write config values to `.git/config`, takes a key/value pair as parameter.\n + */\n void git_config_set(const char *, const char *);\n ++\n int git_config_parse_key(const char *, char **, int *);\n int git_config_key_is_valid(const char *key);\n int git_config_set_multivar_gently(const char *, const char *, const char *, int);\n @@ -214,8 +547,10 @@\n + * the section will be removed from the config file.\n + */\n int git_config_rename_section(const char *, const char *);\n ++\n int git_config_rename_section_in_file(const char *, const char *, const char *);\n int git_config_copy_section(const char *, const char *);\n + int git_config_copy_section_in_file(const char *, const char *, const char *);\n @@\n const char *current_config_origin_type(void);\n const char *current_config_name(void);\n @@ -325,8 +660,10 @@\n + * is owned by the cache.\n + */\n int git_configset_get_value(struct config_set *cs, const char *key, const char **dest);\n ++\n int git_configset_get_string_const(struct config_set *cs, const char *key, const char **dest);\n int git_configset_get_string(struct config_set *cs, const char *key, char **dest);\n + int git_configset_get_int(struct config_set *cs, const char *key, int *dest);\n @@\n int repo_config_get_pathname(struct repository *repo,\n \t\t\t const char *key, const char **dest);\n @@ -418,8 +755,10 @@\n + * the user's home directory when found at the beginning of the path.\n + */\n int git_config_get_pathname(const char *key, const char **dest);\n ++\n int git_config_get_index_threads(int *dest);\n int git_config_get_untracked_cache(void);\n + int git_config_get_split_index(void);\n @@\n \tenum config_scope scope;\n };\n\n-- \ngitgitgadget\n"},{"id":"384574","messageId":"1a9aa33b4649e2b723a6107520c2b5ad70774714.1571727906.git.gitgitgadget@gmail.com","threadId":"52062","inReplyTo":"pull.405.v2.git.1571727906.gitgitgadget@gmail.com","subject":"[PATCH v2 1/1] config: move documentation to config.h","fromName":"Heba Waly via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-10-22T07:05:06Z","receivedAt":"2019-10-22T07:05:14Z","isPatch":true,"sender":{"key":"heba.waly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1539076?v=4"},"body":"From: Heba Waly \n\nMove the documentation from Documentation/technical/api-config.txt into\nconfig.h\nSigned-off-by: Heba Waly \n---\n Documentation/technical/api-config.txt | 319 -----------------------\n config.h | 336 +++++++++++++++++++++++++\n 2 files changed, 336 insertions(+), 319 deletions(-)\n delete mode 100644 Documentation/technical/api-config.txt\n\ndiff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt\ndeleted file mode 100644\nindex 7d20716c32..0000000000\n--- a/Documentation/technical/api-config.txt\n+++ /dev/null\n@@ -1,319 +0,0 @@\n-config API\n-==========\n-\n-The config API gives callers a way to access Git configuration files\n-(and files which have the same syntax). See linkgit:git-config[1] for a\n-discussion of the config file syntax.\n-\n-General Usage\n--------------\n-\n-Config files are parsed linearly, and each variable found is passed to a\n-caller-provided callback function. The callback function is responsible\n-for any actions to be taken on the config option, and is free to ignore\n-some options. It is not uncommon for the configuration to be parsed\n-several times during the run of a Git program, with different callbacks\n-picking out different variables useful to themselves.\n-\n-A config callback function takes three parameters:\n-\n-- the name of the parsed variable. This is in canonical \"flat\" form: the\n- section, subsection, and variable segments will be separated by dots,\n- and the section and variable segments will be all lowercase. E.g.,\n- `core.ignorecase`, `diff.SomeType.textconv`.\n-\n-- the value of the found variable, as a string. If the variable had no\n- value specified, the value will be NULL (typically this means it\n- should be interpreted as boolean true).\n-\n-- a void pointer passed in by the caller of the config API; this can\n- contain callback-specific data\n-\n-A config callback should return 0 for success, or -1 if the variable\n-could not be parsed properly.\n-\n-Basic Config Querying\n----------------------\n-\n-Most programs will simply want to look up variables in all config files\n-that Git knows about, using the normal precedence rules. To do this,\n-call `git_config` with a callback function and void data pointer.\n-\n-`git_config` will read all config sources in order of increasing\n-priority. Thus a callback should typically overwrite previously-seen\n-entries with new ones (e.g., if both the user-wide `~/.gitconfig` and\n-repo-specific `.git/config` contain `color.ui`, the config machinery\n-will first feed the user-wide one to the callback, and then the\n-repo-specific one; by overwriting, the higher-priority repo-specific\n-value is left at the end).\n-\n-The `config_with_options` function lets the caller examine config\n-while adjusting some of the default behavior of `git_config`. It should\n-almost never be used by \"regular\" Git code that is looking up\n-configuration variables. It is intended for advanced callers like\n-`git-config`, which are intentionally tweaking the normal config-lookup\n-process. It takes two extra parameters:\n-\n-`config_source`::\n-If this parameter is non-NULL, it specifies the source to parse for\n-configuration, rather than looking in the usual files. See `struct\n-git_config_source` in `config.h` for details. Regular `git_config` defaults\n-to `NULL`.\n-\n-`opts`::\n-Specify options to adjust the behavior of parsing config files. See `struct\n-config_options` in `config.h` for details. As an example: regular `git_config`\n-sets `opts.respect_includes` to `1` by default.\n-\n-Reading Specific Files\n-----------------------\n-\n-To read a specific file in git-config format, use\n-`git_config_from_file`. This takes the same callback and data parameters\n-as `git_config`.\n-\n-Querying For Specific Variables\n--------------------------------\n-\n-For programs wanting to query for specific variables in a non-callback\n-manner, the config API provides two functions `git_config_get_value`\n-and `git_config_get_value_multi`. They both read values from an internal\n-cache generated previously from reading the config files.\n-\n-`int git_config_get_value(const char *key, const char **value)`::\n-\n-\tFinds the highest-priority value for the configuration variable `key`,\n-\tstores the pointer to it in `value` and returns 0. When the\n-\tconfiguration variable `key` is not found, returns 1 without touching\n-\t`value`. The caller should not free or modify `value`, as it is owned\n-\tby the cache.\n-\n-`const struct string_list *git_config_get_value_multi(const char *key)`::\n-\n-\tFinds and returns the value list, sorted in order of increasing priority\n-\tfor the configuration variable `key`. When the configuration variable\n-\t`key` is not found, returns NULL. The caller should not free or modify\n-\tthe returned pointer, as it is owned by the cache.\n-\n-`void git_config_clear(void)`::\n-\n-\tResets and invalidates the config cache.\n-\n-The config API also provides type specific API functions which do conversion\n-as well as retrieval for the queried variable, including:\n-\n-`int git_config_get_int(const char *key, int *dest)`::\n-\n-\tFinds and parses the value to an integer for the configuration variable\n-\t`key`. Dies on error; otherwise, stores the value of the parsed integer in\n-\t`dest` and returns 0. When the configuration variable `key` is not found,\n-\treturns 1 without touching `dest`.\n-\n-`int git_config_get_ulong(const char *key, unsigned long *dest)`::\n-\n-\tSimilar to `git_config_get_int` but for unsigned longs.\n-\n-`int git_config_get_bool(const char *key, int *dest)`::\n-\n-\tFinds and parses the value into a boolean value, for the configuration\n-\tvariable `key` respecting keywords like \"true\" and \"false\". Integer\n-\tvalues are converted into true/false values (when they are non-zero or\n-\tzero, respectively). Other values cause a die(). If parsing is successful,\n-\tstores the value of the parsed result in `dest` and returns 0. When the\n-\tconfiguration variable `key` is not found, returns 1 without touching\n-\t`dest`.\n-\n-`int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest)`::\n-\n-\tSimilar to `git_config_get_bool`, except that integers are copied as-is,\n-\tand `is_bool` flag is unset.\n-\n-`int git_config_get_maybe_bool(const char *key, int *dest)`::\n-\n-\tSimilar to `git_config_get_bool`, except that it returns -1 on error\n-\trather than dying.\n-\n-`int git_config_get_string_const(const char *key, const char **dest)`::\n-\n-\tAllocates and copies the retrieved string into the `dest` parameter for\n-\tthe configuration variable `key`; if NULL string is given, prints an\n-\terror message and returns -1. When the configuration variable `key` is\n-\tnot found, returns 1 without touching `dest`.\n-\n-`int git_config_get_string(const char *key, char **dest)`::\n-\n-\tSimilar to `git_config_get_string_const`, except that retrieved value\n-\tcopied into the `dest` parameter is a mutable string.\n-\n-`int git_config_get_pathname(const char *key, const char **dest)`::\n-\n-\tSimilar to `git_config_get_string`, but expands `~` or `~user` into\n-\tthe user's home directory when found at the beginning of the path.\n-\n-`git_die_config(const char *key, const char *err, ...)`::\n-\n-\tFirst prints the error message specified by the caller in `err` and then\n-\tdies printing the line number and the file name of the highest priority\n-\tvalue for the configuration variable `key`.\n-\n-`void git_die_config_linenr(const char *key, const char *filename, int linenr)`::\n-\n-\tHelper function which formats the die error message according to the\n-\tparameters entered. Used by `git_die_config()`. It can be used by callers\n-\thandling `git_config_get_value_multi()` to print the correct error message\n-\tfor the desired value.\n-\n-See test-config.c for usage examples.\n-\n-Value Parsing Helpers\n----------------------\n-\n-To aid in parsing string values, the config API provides callbacks with\n-a number of helper functions, including:\n-\n-`git_config_int`::\n-Parse the string to an integer, including unit factors. Dies on error;\n-otherwise, returns the parsed result.\n-\n-`git_config_ulong`::\n-Identical to `git_config_int`, but for unsigned longs.\n-\n-`git_config_bool`::\n-Parse a string into a boolean value, respecting keywords like \"true\" and\n-\"false\". Integer values are converted into true/false values (when they\n-are non-zero or zero, respectively). Other values cause a die(). If\n-parsing is successful, the return value is the result.\n-\n-`git_config_bool_or_int`::\n-Same as `git_config_bool`, except that integers are returned as-is, and\n-an `is_bool` flag is unset.\n-\n-`git_parse_maybe_bool`::\n-Same as `git_config_bool`, except that it returns -1 on error rather\n-than dying.\n-\n-`git_config_string`::\n-Allocates and copies the value string into the `dest` parameter; if no\n-string is given, prints an error message and returns -1.\n-\n-`git_config_pathname`::\n-Similar to `git_config_string`, but expands `~` or `~user` into the\n-user's home directory when found at the beginning of the path.\n-\n-Include Directives\n-------------------\n-\n-By default, the config parser does not respect include directives.\n-However, a caller can use the special `git_config_include` wrapper\n-callback to support them. To do so, you simply wrap your \"real\" callback\n-function and data pointer in a `struct config_include_data`, and pass\n-the wrapper to the regular config-reading functions. For example:\n-\n--------------------------------------------\n-int read_file_with_include(const char *file, config_fn_t fn, void *data)\n-{\n-\tstruct config_include_data inc = CONFIG_INCLUDE_INIT;\n-\tinc.fn = fn;\n-\tinc.data = data;\n-\treturn git_config_from_file(git_config_include, file, &inc);\n-}\n--------------------------------------------\n-\n-`git_config` respects includes automatically. The lower-level\n-`git_config_from_file` does not.\n-\n-Custom Configsets\n------------------\n-\n-A `config_set` can be used to construct an in-memory cache for\n-config-like files that the caller specifies (i.e., files like `.gitmodules`,\n-`~/.gitconfig` etc.). For example,\n-\n-----------------------------------------\n-struct config_set gm_config;\n-git_configset_init(&gm_config);\n-int b;\n-/* we add config files to the config_set */\n-git_configset_add_file(&gm_config, \".gitmodules\");\n-git_configset_add_file(&gm_config, \".gitmodules_alt\");\n-\n-if (!git_configset_get_bool(gm_config, \"submodule.frotz.ignore\", &b)) {\n-\t/* hack hack hack */\n-}\n-\n-/* when we are done with the configset */\n-git_configset_clear(&gm_config);\n-----------------------------------------\n-\n-Configset API provides functions for the above mentioned work flow, including:\n-\n-`void git_configset_init(struct config_set *cs)`::\n-\n-\tInitializes the config_set `cs`.\n-\n-`int git_configset_add_file(struct config_set *cs, const char *filename)`::\n-\n-\tParses the file and adds the variable-value pairs to the `config_set`,\n-\tdies if there is an error in parsing the file. Returns 0 on success, or\n-\t-1 if the file does not exist or is inaccessible. The user has to decide\n-\tif he wants to free the incomplete configset or continue using it when\n-\tthe function returns -1.\n-\n-`int git_configset_get_value(struct config_set *cs, const char *key, const char **value)`::\n-\n-\tFinds the highest-priority value for the configuration variable `key`\n-\tand config set `cs`, stores the pointer to it in `value` and returns 0.\n-\tWhen the configuration variable `key` is not found, returns 1 without\n-\ttouching `value`. The caller should not free or modify `value`, as it\n-\tis owned by the cache.\n-\n-`const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key)`::\n-\n-\tFinds and returns the value list, sorted in order of increasing priority\n-\tfor the configuration variable `key` and config set `cs`. When the\n-\tconfiguration variable `key` is not found, returns NULL. The caller\n-\tshould not free or modify the returned pointer, as it is owned by the cache.\n-\n-`void git_configset_clear(struct config_set *cs)`::\n-\n-\tClears `config_set` structure, removes all saved variable-value pairs.\n-\n-In addition to above functions, the `config_set` API provides type specific\n-functions in the vein of `git_config_get_int` and family but with an extra\n-parameter, pointer to struct `config_set`.\n-They all behave similarly to the `git_config_get*()` family described in\n-\"Querying For Specific Variables\" above.\n-\n-Writing Config Files\n---------------------\n-\n-Git gives multiple entry points in the Config API to write config values to\n-files namely `git_config_set_in_file` and `git_config_set`, which write to\n-a specific config file or to `.git/config` respectively. They both take a\n-key/value pair as parameter.\n-In the end they both call `git_config_set_multivar_in_file` which takes four\n-parameters:\n-\n-- the name of the file, as a string, to which key/value pairs will be written.\n-\n-- the name of key, as a string. This is in canonical \"flat\" form: the section,\n- subsection, and variable segments will be separated by dots, and the section\n- and variable segments will be all lowercase.\n- E.g., `core.ignorecase`, `diff.SomeType.textconv`.\n-\n-- the value of the variable, as a string. If value is equal to NULL, it will\n- remove the matching key from the config file.\n-\n-- the value regex, as a string. It will disregard key/value pairs where value\n- does not match.\n-\n-- a multi_replace value, as an int. If value is equal to zero, nothing or only\n- one matching key/value is replaced, else all matching key/values (regardless\n- how many) are removed, before the new pair is written.\n-\n-It returns 0 on success.\n-\n-Also, there are functions `git_config_rename_section` and\n-`git_config_rename_section_in_file` with parameters `old_name` and `new_name`\n-for renaming or removing sections in the config files. If NULL is passed\n-through `new_name` parameter, the section will be removed from the config file.\ndiff --git a/config.h b/config.h\nindex f0ed464004..02f78ffc2b 100644\n--- a/config.h\n+++ b/config.h\n@@ -4,6 +4,23 @@\n #include \"hashmap.h\"\n #include \"string-list.h\"\n \n+\n+/**\n+ * The config API gives callers a way to access Git configuration files\n+ * (and files which have the same syntax). See linkgit:git-config[1] for a\n+ * discussion of the config file syntax.\n+ *\n+ * General Usage\n+ * -------------\n+ *\n+ * Config files are parsed linearly, and each variable found is passed to a\n+ * caller-provided callback function. The callback function is responsible\n+ * for any actions to be taken on the config option, and is free to ignore\n+ * some options. It is not uncommon for the configuration to be parsed\n+ * several times during the run of a Git program, with different callbacks\n+ * picking out different variables useful to themselves.\n+ */\n+\n struct object_id;\n \n /* git_config_parse_key() returns these negated: */\n@@ -71,9 +88,34 @@ struct config_options {\n \t} error_action;\n };\n \n+/**\n+ * A config callback function takes three parameters:\n+ *\n+ * - the name of the parsed variable. This is in canonical \"flat\" form: the\n+ * section, subsection, and variable segments will be separated by dots,\n+ * and the section and variable segments will be all lowercase. E.g.,\n+ * `core.ignorecase`, `diff.SomeType.textconv`.\n+ *\n+ * - the value of the found variable, as a string. If the variable had no\n+ * value specified, the value will be NULL (typically this means it\n+ * should be interpreted as boolean true).\n+ *\n+ * - a void pointer passed in by the caller of the config API; this can\n+ * contain callback-specific data\n+ *\n+ * A config callback should return 0 for success, or -1 if the variable\n+ * could not be parsed properly.\n+ */\n typedef int (*config_fn_t)(const char *, const char *, void *);\n+\n int git_default_config(const char *, const char *, void *);\n+\n+/**\n+ * Read a specific file in git-config format.\n+ * This function takes the same callback and data parameters as `git_config`.\n+ */\n int git_config_from_file(config_fn_t fn, const char *, void *);\n+\n int git_config_from_file_with_options(config_fn_t fn, const char *,\n \t\t\t\t void *,\n \t\t\t\t const struct config_options *);\n@@ -88,34 +130,157 @@ void git_config_push_parameter(const char *text);\n int git_config_from_parameters(config_fn_t fn, void *data);\n void read_early_config(config_fn_t cb, void *data);\n void read_very_early_config(config_fn_t cb, void *data);\n+\n+/**\n+ * Most programs will simply want to look up variables in all config files\n+ * that Git knows about, using the normal precedence rules. To do this,\n+ * call `git_config` with a callback function and void data pointer.\n+ *\n+ * `git_config` will read all config sources in order of increasing\n+ * priority. Thus a callback should typically overwrite previously-seen\n+ * entries with new ones (e.g., if both the user-wide `~/.gitconfig` and\n+ * repo-specific `.git/config` contain `color.ui`, the config machinery\n+ * will first feed the user-wide one to the callback, and then the\n+ * repo-specific one; by overwriting, the higher-priority repo-specific\n+ * value is left at the end).\n+ */\n void git_config(config_fn_t fn, void *);\n+\n+/**\n+ * Lets the caller examine config while adjusting some of the default\n+ * behavior of `git_config`. It should almost never be used by \"regular\"\n+ * Git code that is looking up configuration variables.\n+ * It is intended for advanced callers like `git-config`, which are\n+ * intentionally tweaking the normal config-lookup process.\n+ * It takes two extra parameters:\n+ *\n+ * - `config_source`\n+ * If this parameter is non-NULL, it specifies the source to parse for\n+ * configuration, rather than looking in the usual files. See `struct\n+ * git_config_source` in `config.h` for details. Regular `git_config` defaults\n+ * to `NULL`.\n+ *\n+ * - `opts`\n+ * Specify options to adjust the behavior of parsing config files. See `struct\n+ * config_options` in `config.h` for details. As an example: regular `git_config`\n+ * sets `opts.respect_includes` to `1` by default.\n+ */\n int config_with_options(config_fn_t fn, void *,\n \t\t\tstruct git_config_source *config_source,\n \t\t\tconst struct config_options *opts);\n+\n+/**\n+ * Value Parsing Helpers\n+ * ---------------------\n+ *\n+ * The following helper functions aid in parsing string values\n+ */\n+\n int git_parse_ssize_t(const char *, ssize_t *);\n int git_parse_ulong(const char *, unsigned long *);\n+\n+/**\n+ * Same as `git_config_bool`, except that it returns -1 on error rather\n+ * than dying.\n+ */\n int git_parse_maybe_bool(const char *);\n+\n+/**\n+ * Parse the string to an integer, including unit factors. Dies on error;\n+ * otherwise, returns the parsed result.\n+ */\n int git_config_int(const char *, const char *);\n+\n int64_t git_config_int64(const char *, const char *);\n+\n+/**\n+ * Identical to `git_config_int`, but for unsigned longs.\n+ */\n unsigned long git_config_ulong(const char *, const char *);\n+\n ssize_t git_config_ssize_t(const char *, const char *);\n+\n+/**\n+ * Same as `git_config_bool`, except that integers are returned as-is, and\n+ * an `is_bool` flag is unset.\n+ */\n int git_config_bool_or_int(const char *, const char *, int *);\n+\n+/**\n+ * Parse a string into a boolean value, respecting keywords like \"true\" and\n+ * \"false\". Integer values are converted into true/false values (when they\n+ * are non-zero or zero, respectively). Other values cause a die(). If\n+ * parsing is successful, the return value is the result.\n+ */\n int git_config_bool(const char *, const char *);\n+\n+/**\n+ * Allocates and copies the value string into the `dest` parameter; if no\n+ * string is given, prints an error message and returns -1.\n+ */\n int git_config_string(const char **, const char *, const char *);\n+\n+/**\n+ * Similar to `git_config_string`, but expands `~` or `~user` into the\n+ * user's home directory when found at the beginning of the path.\n+ */\n int git_config_pathname(const char **, const char *, const char *);\n+\n int git_config_expiry_date(timestamp_t *, const char *, const char *);\n int git_config_color(char *, const char *, const char *);\n int git_config_set_in_file_gently(const char *, const char *, const char *);\n+\n+/**\n+ * write config values to a specific config file, takes a key/value pair as\n+ * parameter.\n+ */\n void git_config_set_in_file(const char *, const char *, const char *);\n+\n int git_config_set_gently(const char *, const char *);\n+\n+/**\n+ * write config values to `.git/config`, takes a key/value pair as parameter.\n+ */\n void git_config_set(const char *, const char *);\n+\n int git_config_parse_key(const char *, char **, int *);\n int git_config_key_is_valid(const char *key);\n int git_config_set_multivar_gently(const char *, const char *, const char *, int);\n void git_config_set_multivar(const char *, const char *, const char *, int);\n int git_config_set_multivar_in_file_gently(const char *, const char *, const char *, const char *, int);\n+\n+/**\n+ * takes four parameters:\n+ *\n+ * - the name of the file, as a string, to which key/value pairs will be written.\n+ *\n+ * - the name of key, as a string. This is in canonical \"flat\" form: the section,\n+ * subsection, and variable segments will be separated by dots, and the section\n+ * and variable segments will be all lowercase.\n+ * E.g., `core.ignorecase`, `diff.SomeType.textconv`.\n+ *\n+ * - the value of the variable, as a string. If value is equal to NULL, it will\n+ * remove the matching key from the config file.\n+ *\n+ * - the value regex, as a string. It will disregard key/value pairs where value\n+ * does not match.\n+ *\n+ * - a multi_replace value, as an int. If value is equal to zero, nothing or only\n+ * one matching key/value is replaced, else all matching key/values (regardless\n+ * how many) are removed, before the new pair is written.\n+ *\n+ * It returns 0 on success.\n+ */\n void git_config_set_multivar_in_file(const char *, const char *, const char *, const char *, int);\n+\n+/**\n+ * rename or remove sections in the config file\n+ * parameters `old_name` and `new_name`\n+ * If NULL is passed through `new_name` parameter,\n+ * the section will be removed from the config file.\n+ */\n int git_config_rename_section(const char *, const char *);\n+\n int git_config_rename_section_in_file(const char *, const char *, const char *);\n int git_config_copy_section(const char *, const char *);\n int git_config_copy_section_in_file(const char *, const char *, const char *);\n@@ -142,6 +307,30 @@ enum config_scope current_config_scope(void);\n const char *current_config_origin_type(void);\n const char *current_config_name(void);\n \n+/**\n+ * Include Directives\n+ * ------------------\n+ *\n+ * By default, the config parser does not respect include directives.\n+ * However, a caller can use the special `git_config_include` wrapper\n+ * callback to support them. To do so, you simply wrap your \"real\" callback\n+ * function and data pointer in a `struct config_include_data`, and pass\n+ * the wrapper to the regular config-reading functions. For example:\n+ *\n+ * -------------------------------------------\n+ * int read_file_with_include(const char *file, config_fn_t fn, void *data)\n+ * {\n+ * struct config_include_data inc = CONFIG_INCLUDE_INIT;\n+ * inc.fn = fn;\n+ * inc.data = data;\n+ * return git_config_from_file(git_config_include, file, &inc);\n+ * }\n+ * -------------------------------------------\n+ *\n+ * `git_config` respects includes automatically. The lower-level\n+ * `git_config_from_file` does not.\n+ *\n+ */\n struct config_include_data {\n \tint depth;\n \tconfig_fn_t fn;\n@@ -169,6 +358,33 @@ int parse_config_key(const char *var,\n \t\t const char **subsection, int *subsection_len,\n \t\t const char **key);\n \n+/**\n+ * Custom Configsets\n+ * -----------------\n+ *\n+ * A `config_set` can be used to construct an in-memory cache for\n+ * config-like files that the caller specifies (i.e., files like `.gitmodules`,\n+ * `~/.gitconfig` etc.). For example,\n+ *\n+ * ----------------------------------------\n+ * struct config_set gm_config;\n+ * git_configset_init(&gm_config);\n+ * int b;\n+ * //we add config files to the config_set\n+ * git_configset_add_file(&gm_config, \".gitmodules\");\n+ * git_configset_add_file(&gm_config, \".gitmodules_alt\");\n+ *\n+ * if (!git_configset_get_bool(gm_config, \"submodule.frotz.ignore\", &b)) {\n+ * //hack hack hack\n+ * }\n+ *\n+ * when we are done with the configset:\n+ * git_configset_clear(&gm_config);\n+ * ----------------------------------------\n+ *\n+ * Configset API provides functions for the above mentioned work flow\n+ */\n+\n struct config_set_element {\n \tstruct hashmap_entry ent;\n \tchar *key;\n@@ -197,16 +413,47 @@ struct config_set {\n \tstruct configset_list list;\n };\n \n+/**\n+ * Initializes the config_set `cs`.\n+ */\n void git_configset_init(struct config_set *cs);\n+\n+/**\n+ * Parses the file and adds the variable-value pairs to the `config_set`,\n+ * dies if there is an error in parsing the file. Returns 0 on success, or\n+ * -1 if the file does not exist or is inaccessible. The user has to decide\n+ * if he wants to free the incomplete configset or continue using it when\n+ * the function returns -1.\n+ */\n int git_configset_add_file(struct config_set *cs, const char *filename);\n+\n+/**\n+ * Finds and returns the value list, sorted in order of increasing priority\n+ * for the configuration variable `key` and config set `cs`. When the\n+ * configuration variable `key` is not found, returns NULL. The caller\n+ * should not free or modify the returned pointer, as it is owned by the cache.\n+ */\n const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key);\n+\n+/**\n+ * Clears `config_set` structure, removes all saved variable-value pairs.\n+ */\n void git_configset_clear(struct config_set *cs);\n \n /*\n * These functions return 1 if not found, and 0 if found, leaving the found\n * value in the 'dest' pointer.\n */\n+\n+/*\n+ * Finds the highest-priority value for the configuration variable `key`\n+ * and config set `cs`, stores the pointer to it in `value` and returns 0.\n+ * When the configuration variable `key` is not found, returns 1 without\n+ * touching `value`. The caller should not free or modify `value`, as it\n+ * is owned by the cache.\n+ */\n int git_configset_get_value(struct config_set *cs, const char *key, const char **dest);\n+\n int git_configset_get_string_const(struct config_set *cs, const char *key, const char **dest);\n int git_configset_get_string(struct config_set *cs, const char *key, char **dest);\n int git_configset_get_int(struct config_set *cs, const char *key, int *dest);\n@@ -240,17 +487,94 @@ int repo_config_get_maybe_bool(struct repository *repo,\n int repo_config_get_pathname(struct repository *repo,\n \t\t\t const char *key, const char **dest);\n \n+/**\n+ * Querying For Specific Variables\n+ * -------------------------------\n+ *\n+ * For programs wanting to query for specific variables in a non-callback\n+ * manner, the config API provides two functions `git_config_get_value`\n+ * and `git_config_get_value_multi`. They both read values from an internal\n+ * cache generated previously from reading the config files.\n+ */\n+\n+/**\n+ * Finds the highest-priority value for the configuration variable `key`,\n+ * stores the pointer to it in `value` and returns 0. When the\n+ * configuration variable `key` is not found, returns 1 without touching\n+ * `value`. The caller should not free or modify `value`, as it is owned\n+ * by the cache.\n+ */\n int git_config_get_value(const char *key, const char **value);\n+\n+/**\n+ * Finds and returns the value list, sorted in order of increasing priority\n+ * for the configuration variable `key`. When the configuration variable\n+ * `key` is not found, returns NULL. The caller should not free or modify\n+ * the returned pointer, as it is owned by the cache.\n+ */\n const struct string_list *git_config_get_value_multi(const char *key);\n+\n+/**\n+ * Resets and invalidates the config cache.\n+ */\n void git_config_clear(void);\n+\n+/**\n+ * Allocates and copies the retrieved string into the `dest` parameter for\n+ * the configuration variable `key`; if NULL string is given, prints an\n+ * error message and returns -1. When the configuration variable `key` is\n+ * not found, returns 1 without touching `dest`.\n+ */\n int git_config_get_string_const(const char *key, const char **dest);\n+\n+/**\n+ * Similar to `git_config_get_string_const`, except that retrieved value\n+ * copied into the `dest` parameter is a mutable string.\n+ */\n int git_config_get_string(const char *key, char **dest);\n+\n+/**\n+ * Finds and parses the value to an integer for the configuration variable\n+ * `key`. Dies on error; otherwise, stores the value of the parsed integer in\n+ * `dest` and returns 0. When the configuration variable `key` is not found,\n+ * returns 1 without touching `dest`.\n+ */\n int git_config_get_int(const char *key, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_int` but for unsigned longs.\n+ */\n int git_config_get_ulong(const char *key, unsigned long *dest);\n+\n+/**\n+ * Finds and parses the value into a boolean value, for the configuration\n+ * variable `key` respecting keywords like \"true\" and \"false\". Integer\n+ * values are converted into true/false values (when they are non-zero or\n+ * zero, respectively). Other values cause a die(). If parsing is successful,\n+ * stores the value of the parsed result in `dest` and returns 0. When the\n+ * configuration variable `key` is not found, returns 1 without touching\n+ * `dest`.\n+ */\n int git_config_get_bool(const char *key, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_bool`, except that integers are copied as-is,\n+ * and `is_bool` flag is unset.\n+ */\n int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_bool`, except that it returns -1 on error\n+ * rather than dying.\n+ */\n int git_config_get_maybe_bool(const char *key, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_string`, but expands `~` or `~user` into\n+ * the user's home directory when found at the beginning of the path.\n+ */\n int git_config_get_pathname(const char *key, const char **dest);\n+\n int git_config_get_index_threads(int *dest);\n int git_config_get_untracked_cache(void);\n int git_config_get_split_index(void);\n@@ -270,7 +594,19 @@ struct key_value_info {\n \tenum config_scope scope;\n };\n \n+/**\n+ * First prints the error message specified by the caller in `err` and then\n+ * dies printing the line number and the file name of the highest priority\n+ * value for the configuration variable `key`.\n+ */\n NORETURN void git_die_config(const char *key, const char *err, ...) __attribute__((format(printf, 2, 3)));\n+\n+/**\n+ * Helper function which formats the die error message according to the\n+ * parameters entered. Used by `git_die_config()`. It can be used by callers\n+ * handling `git_config_get_value_multi()` to print the correct error message\n+ * for the desired value.\n+ */\n NORETURN void git_die_config_linenr(const char *key, const char *filename, int linenr);\n \n #define LOOKUP_CONFIG(mapping, var) \\\n-- \ngitgitgadget\n"},{"id":"384628","messageId":"20191022204259.GC9323@google.com","threadId":"52062","inReplyTo":"CACg5j26DuAUm9WR9-4awF7BeGCy81d5kMhhcsePyp3Kxh2DTGg@mail.gmail.com","subject":"Re: [PATCH 1/1] config: add documentation to config.h","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-22T20:42:59Z","receivedAt":"2019-10-22T20:43:07Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Sun, Oct 20, 2019 at 09:35:17PM +1300, Heba Waly wrote:\n> On Sat, Oct 19, 2019 at 11:52 AM Emily Shaffer wrote:\n> >\n> > On Fri, Oct 18, 2019 at 12:06:59AM +0000, Heba Waly via GitGitGadget wrote:\n> > > From: Heba Waly \n> >\n> > Hi Heba,\n> >\n> > Thanks for the patch!\n> >\n> > I'd like to highlight to the community that this is an Outreachy\n> > applicant and microproject. Heba, when you send the next version, I\n> > think you can add [Outreachy] manually to the PR subject line - that\n> > should draw the attention of those in the community who are invested in\n> > helping Outreachy applicants.\n> Good idea! I wanted to add it to the email subject but as I decided to\n> use gitgadget\n> I had no control over the subject.\n\nHm, it looks like you already figured out how to add it to the title of\nthe PR. :)\n\n> > >\n> > > This commit is copying and summarizing the documentation from\n> > > documentation/technical/api-config.txt to comments in config.h\n> >\n> > I think in the GitGitGadget PR you've got some great comments from Dscho\n> > about how to format your commit message; please take a look at those and\n> > feel free to reach out to me if you're still not sure what's missing or\n> > not.\n> Will do.\n> > > Signed-off-by: Heba Waly \n> >\n> > One thing I miss in this change is the removal of the contents of\n> > Documentation/technical/api-config.txt (or maybe the removal of the file\n> > itself). I'd prefer to see at least for api-config.txt to say something\n> > like \"Please refer to comments in 'config.h'\"; or, more drastically, for\n> > api-config.txt to be removed entirely.\n> >\n> > Having both pieces of documentation standing independently means that\n> > someone who's trying to add new information about the config API won't\n> > know where to add it; eventually they'll add something to config.h but\n> > not api-config.txt, or vice versa, and the two documents will go out of\n> > sync. So we want to move the documentation, rather than copy it.\n> That makes sense, thanks for the explanation.\n> I wasn't sure if it should be removed or not so I decided to leave it\n> until I'm asked otherwise.\n> So I assume api-config.html will be removed too?\n\nThat shouldn't be tracked - this is generated from api-config.txt as\npart of the build. So don't worry about this part.\n\n> > > +\n> > > +/**\n> > > + * Value Parsing Helpers\n> > > + * ---------------------\n> >\n> > It may not make sense to have the header here in the middle of the doc.\n> >\n> > I wonder whether we need the headers at all anymore; or, whether it\n> > makes more sense to put this header in the long comment at the top with\n> > just the list of function names (so someone knows where to look), and\n> > leave the per-function explanations inline with the function they\n> > describe?\n> I see your point Emily, but in the CodingGuidelines file it was\n> advised to refer to strbuf.h\n> as a model for documentation, I noticed that strbuf.h used headers\n> this way so I decided\n> to replicate that.\n\nOk! Sure.\n\n> > I made a couple of smallish comments about general formatting, but I'm\n> > also interested to know whether you were able to move the entire\n> > contents of api-config.txt across to here. Was there anything that you\n> > couldn't find a place for?\n> Yes, everything is moved.\n> > Thanks a lot for this change, and congrats on getting your first review\n> > out! Welcome! :)\n> >\n> > - Emily\n> >\n> Thanks a lot Emily for the detailed and helpful feedback!\n> \n> Heba\n"},{"id":"384629","messageId":"20191022205941.GD9323@google.com","threadId":"52062","inReplyTo":"1a9aa33b4649e2b723a6107520c2b5ad70774714.1571727906.git.gitgitgadget@gmail.com","subject":"Re: [PATCH v2 1/1] config: move documentation to config.h","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-22T20:59:41Z","receivedAt":"2019-10-22T20:59:49Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Tue, Oct 22, 2019 at 07:05:06AM +0000, Heba Waly via GitGitGadget wrote:\n> From: Heba Waly \n> \n> Move the documentation from Documentation/technical/api-config.txt into\n> config.h\n\nThis is still a little thin for what we usually want from commit\nmessages. Try to imagine that five years from now, you find this commit\nby running `git blame` on config.h and then examining the commit which\nintroduced all these comments with `git show ` - what would\nyou want to know?\n\nTypically we want to know \"why\" the change was made, because the diff\nshows \"what\". We can see from the diff that you're moving comments from\nA to B, but if you explain why you did so (not \"because my Outreachy\nmentor told me to\" ;) but \"because it is useful to see usage information\nnext to code\" or \"this is best practice as described by blah blah\") - I\nwouldn't be able to know that reasoning just from looking at your diff.\n\n\n> diff --git a/config.h b/config.h\n> index f0ed464004..02f78ffc2b 100644\n> --- a/config.h\n> +++ b/config.h\n> @@ -4,6 +4,23 @@\n> #include \"hashmap.h\"\n> #include \"string-list.h\"\n> \n> +\n> +/**\n> + * The config API gives callers a way to access Git configuration files\n> + * (and files which have the same syntax). See linkgit:git-config[1] for a\n\nAh, here's another place where the Asciidoc link isn't going to do\nanything anymore.\n\nOtherwise I didn't still see anything jumping out. When the commit\nmessage is cleaned up I'm ready to add my Reviewed-by line.\n\n - Emily\n"},{"id":"384663","messageId":"xmqq8spcjjhp.fsf@gitster-ct.c.googlers.com","threadId":"52062","inReplyTo":"20191022205941.GD9323@google.com","subject":"Re: [PATCH v2 1/1] config: move documentation to config.h","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-10-23T02:14:42Z","receivedAt":"2019-10-23T02:14:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emily Shaffer writes:\n\n>> ...\n>> +/**\n>> + * The config API gives callers a way to access Git configuration files\n>> + * (and files which have the same syntax). See linkgit:git-config[1] for a\n>\n> Ah, here's another place where the Asciidoc link isn't going to do\n> anything anymore.\n>\n> Otherwise I didn't still see anything jumping out. When the commit\n> message is cleaned up I'm ready to add my Reviewed-by line.\n\nThanks. Your review(s) have been quite sensible and helpful.\n\n\n"},{"id":"384674","messageId":"CACg5j275CdwQcj1RvjtYNQpWPdtkTAT1WX6X12_cKwFH11JTQQ@mail.gmail.com","threadId":"52062","inReplyTo":"20191022205941.GD9323@google.com","subject":"Re: [PATCH v2 1/1] config: move documentation to config.h","fromName":"Heba Waly","fromEmail":"heba.waly@gmail.com","sentAt":"2019-10-23T04:55:12Z","receivedAt":"2019-10-23T04:55:26Z","isPatch":true,"sender":{"key":"heba.waly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1539076?v=4"},"body":"On Wed, Oct 23, 2019 at 9:59 AM Emily Shaffer wrote:\n>\n> On Tue, Oct 22, 2019 at 07:05:06AM +0000, Heba Waly via GitGitGadget wrote:\n> > From: Heba Waly \n> >\n> > Move the documentation from Documentation/technical/api-config.txt into\n> > config.h\n>\n> This is still a little thin for what we usually want from commit\n> messages. Try to imagine that five years from now, you find this commit\n> by running `git blame` on config.h and then examining the commit which\n> introduced all these comments with `git show ` - what would\n> you want to know?\n>\n> Typically we want to know \"why\" the change was made, because the diff\n> shows \"what\". We can see from the diff that you're moving comments from\n> A to B, but if you explain why you did so (not \"because my Outreachy\n> mentor told me to\" ;) but \"because it is useful to see usage information\n> next to code\" or \"this is best practice as described by blah blah\") - I\n> wouldn't be able to know that reasoning just from looking at your diff.\nOk, got it.\n\n>\n> > diff --git a/config.h b/config.h\n> > index f0ed464004..02f78ffc2b 100644\n> > --- a/config.h\n> > +++ b/config.h\n> > @@ -4,6 +4,23 @@\n> > #include \"hashmap.h\"\n> > #include \"string-list.h\"\n> >\n> > +\n> > +/**\n> > + * The config API gives callers a way to access Git configuration files\n> > + * (and files which have the same syntax). See linkgit:git-config[1] for a\n>\n> Ah, here's another place where the Asciidoc link isn't going to do\n> anything anymore.\nyep!\n> Otherwise I didn't still see anything jumping out. When the commit\n> message is cleaned up I'm ready to add my Reviewed-by line.\ngreat!\n\n> - Emily\n\nThanks :)\n"},{"id":"384676","messageId":"pull.405.v3.git.1571808652.gitgitgadget@gmail.com","threadId":"52062","inReplyTo":"pull.405.v2.git.1571727906.gitgitgadget@gmail.com","subject":"[PATCH v3 0/1] [Outreachy] config: move documentation to config.h","fromName":"Heba Waly via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-10-23T05:30:51Z","receivedAt":"2019-10-23T05:30:58Z","isPatch":true,"sender":{"key":"heba.waly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1539076?v=4"},"body":"Move the documentation from Documentation/technical/api-config.txt into\nconfig.h as it's easier for the developers to find the usage information\nbeside the code instead of looking for it in another doc file, also\ndocumentation/technical/api-config.txt is removed because the information it\nhas is now redundant and it'll be hard to keep it up to date and\nsynchronized with the documentation in config.h\n\nSigned-off-by: Heba Waly heba.waly@gmail.com [heba.waly@gmail.com]\n\nHeba Waly (1):\n config: move documentation to config.h\n\n Documentation/technical/api-config.txt | 319 -----------------------\n config.h | 335 +++++++++++++++++++++++++\n 2 files changed, 335 insertions(+), 319 deletions(-)\n delete mode 100644 Documentation/technical/api-config.txt\n\n\nbase-commit: 108b97dc372828f0e72e56bbb40cae8e1e83ece6\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-405%2FHebaWaly%2Fconfig_documentation-v3\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-405/HebaWaly/config_documentation-v3\nPull-Request: https://github.com/gitgitgadget/git/pull/405\n\nRange-diff vs v2:\n\n 1: 1a9aa33b46 ! 1: d6cbb3197a config: move documentation to config.h\n @@ -3,7 +3,12 @@\n config: move documentation to config.h\n \n Move the documentation from Documentation/technical/api-config.txt into\n - config.h\n + config.h as it's easier for the developers to find the usage information\n + beside the code instead of looking for it in another doc file, also\n + documentation/technical/api-config.txt is removed because the information\n + it has is now redundant and it'll be hard to keep it up to date and\n + syncronized with the documentation in config.h\n +\n Signed-off-by: Heba Waly \n \n diff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt\n @@ -341,8 +346,7 @@\n +\n +/**\n + * The config API gives callers a way to access Git configuration files\n -+ * (and files which have the same syntax). See linkgit:git-config[1] for a\n -+ * discussion of the config file syntax.\n ++ * (and files which have the same syntax).\n + *\n + * General Usage\n + * -------------\n\n-- \ngitgitgadget\n"},{"id":"384677","messageId":"d6cbb3197af2c59f0222c7806ab6a6fcdf83869a.1571808652.git.gitgitgadget@gmail.com","threadId":"52062","inReplyTo":"pull.405.v3.git.1571808652.gitgitgadget@gmail.com","subject":"[PATCH v3 1/1] config: move documentation to config.h","fromName":"Heba Waly via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2019-10-23T05:30:52Z","receivedAt":"2019-10-23T05:31:01Z","isPatch":true,"sender":{"key":"heba.waly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1539076?v=4"},"body":"From: Heba Waly \n\nMove the documentation from Documentation/technical/api-config.txt into\nconfig.h as it's easier for the developers to find the usage information\nbeside the code instead of looking for it in another doc file, also\ndocumentation/technical/api-config.txt is removed because the information\nit has is now redundant and it'll be hard to keep it up to date and\nsyncronized with the documentation in config.h\n\nSigned-off-by: Heba Waly \n---\n Documentation/technical/api-config.txt | 319 -----------------------\n config.h | 335 +++++++++++++++++++++++++\n 2 files changed, 335 insertions(+), 319 deletions(-)\n delete mode 100644 Documentation/technical/api-config.txt\n\ndiff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt\ndeleted file mode 100644\nindex 7d20716c32..0000000000\n--- a/Documentation/technical/api-config.txt\n+++ /dev/null\n@@ -1,319 +0,0 @@\n-config API\n-==========\n-\n-The config API gives callers a way to access Git configuration files\n-(and files which have the same syntax). See linkgit:git-config[1] for a\n-discussion of the config file syntax.\n-\n-General Usage\n--------------\n-\n-Config files are parsed linearly, and each variable found is passed to a\n-caller-provided callback function. The callback function is responsible\n-for any actions to be taken on the config option, and is free to ignore\n-some options. It is not uncommon for the configuration to be parsed\n-several times during the run of a Git program, with different callbacks\n-picking out different variables useful to themselves.\n-\n-A config callback function takes three parameters:\n-\n-- the name of the parsed variable. This is in canonical \"flat\" form: the\n- section, subsection, and variable segments will be separated by dots,\n- and the section and variable segments will be all lowercase. E.g.,\n- `core.ignorecase`, `diff.SomeType.textconv`.\n-\n-- the value of the found variable, as a string. If the variable had no\n- value specified, the value will be NULL (typically this means it\n- should be interpreted as boolean true).\n-\n-- a void pointer passed in by the caller of the config API; this can\n- contain callback-specific data\n-\n-A config callback should return 0 for success, or -1 if the variable\n-could not be parsed properly.\n-\n-Basic Config Querying\n----------------------\n-\n-Most programs will simply want to look up variables in all config files\n-that Git knows about, using the normal precedence rules. To do this,\n-call `git_config` with a callback function and void data pointer.\n-\n-`git_config` will read all config sources in order of increasing\n-priority. Thus a callback should typically overwrite previously-seen\n-entries with new ones (e.g., if both the user-wide `~/.gitconfig` and\n-repo-specific `.git/config` contain `color.ui`, the config machinery\n-will first feed the user-wide one to the callback, and then the\n-repo-specific one; by overwriting, the higher-priority repo-specific\n-value is left at the end).\n-\n-The `config_with_options` function lets the caller examine config\n-while adjusting some of the default behavior of `git_config`. It should\n-almost never be used by \"regular\" Git code that is looking up\n-configuration variables. It is intended for advanced callers like\n-`git-config`, which are intentionally tweaking the normal config-lookup\n-process. It takes two extra parameters:\n-\n-`config_source`::\n-If this parameter is non-NULL, it specifies the source to parse for\n-configuration, rather than looking in the usual files. See `struct\n-git_config_source` in `config.h` for details. Regular `git_config` defaults\n-to `NULL`.\n-\n-`opts`::\n-Specify options to adjust the behavior of parsing config files. See `struct\n-config_options` in `config.h` for details. As an example: regular `git_config`\n-sets `opts.respect_includes` to `1` by default.\n-\n-Reading Specific Files\n-----------------------\n-\n-To read a specific file in git-config format, use\n-`git_config_from_file`. This takes the same callback and data parameters\n-as `git_config`.\n-\n-Querying For Specific Variables\n--------------------------------\n-\n-For programs wanting to query for specific variables in a non-callback\n-manner, the config API provides two functions `git_config_get_value`\n-and `git_config_get_value_multi`. They both read values from an internal\n-cache generated previously from reading the config files.\n-\n-`int git_config_get_value(const char *key, const char **value)`::\n-\n-\tFinds the highest-priority value for the configuration variable `key`,\n-\tstores the pointer to it in `value` and returns 0. When the\n-\tconfiguration variable `key` is not found, returns 1 without touching\n-\t`value`. The caller should not free or modify `value`, as it is owned\n-\tby the cache.\n-\n-`const struct string_list *git_config_get_value_multi(const char *key)`::\n-\n-\tFinds and returns the value list, sorted in order of increasing priority\n-\tfor the configuration variable `key`. When the configuration variable\n-\t`key` is not found, returns NULL. The caller should not free or modify\n-\tthe returned pointer, as it is owned by the cache.\n-\n-`void git_config_clear(void)`::\n-\n-\tResets and invalidates the config cache.\n-\n-The config API also provides type specific API functions which do conversion\n-as well as retrieval for the queried variable, including:\n-\n-`int git_config_get_int(const char *key, int *dest)`::\n-\n-\tFinds and parses the value to an integer for the configuration variable\n-\t`key`. Dies on error; otherwise, stores the value of the parsed integer in\n-\t`dest` and returns 0. When the configuration variable `key` is not found,\n-\treturns 1 without touching `dest`.\n-\n-`int git_config_get_ulong(const char *key, unsigned long *dest)`::\n-\n-\tSimilar to `git_config_get_int` but for unsigned longs.\n-\n-`int git_config_get_bool(const char *key, int *dest)`::\n-\n-\tFinds and parses the value into a boolean value, for the configuration\n-\tvariable `key` respecting keywords like \"true\" and \"false\". Integer\n-\tvalues are converted into true/false values (when they are non-zero or\n-\tzero, respectively). Other values cause a die(). If parsing is successful,\n-\tstores the value of the parsed result in `dest` and returns 0. When the\n-\tconfiguration variable `key` is not found, returns 1 without touching\n-\t`dest`.\n-\n-`int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest)`::\n-\n-\tSimilar to `git_config_get_bool`, except that integers are copied as-is,\n-\tand `is_bool` flag is unset.\n-\n-`int git_config_get_maybe_bool(const char *key, int *dest)`::\n-\n-\tSimilar to `git_config_get_bool`, except that it returns -1 on error\n-\trather than dying.\n-\n-`int git_config_get_string_const(const char *key, const char **dest)`::\n-\n-\tAllocates and copies the retrieved string into the `dest` parameter for\n-\tthe configuration variable `key`; if NULL string is given, prints an\n-\terror message and returns -1. When the configuration variable `key` is\n-\tnot found, returns 1 without touching `dest`.\n-\n-`int git_config_get_string(const char *key, char **dest)`::\n-\n-\tSimilar to `git_config_get_string_const`, except that retrieved value\n-\tcopied into the `dest` parameter is a mutable string.\n-\n-`int git_config_get_pathname(const char *key, const char **dest)`::\n-\n-\tSimilar to `git_config_get_string`, but expands `~` or `~user` into\n-\tthe user's home directory when found at the beginning of the path.\n-\n-`git_die_config(const char *key, const char *err, ...)`::\n-\n-\tFirst prints the error message specified by the caller in `err` and then\n-\tdies printing the line number and the file name of the highest priority\n-\tvalue for the configuration variable `key`.\n-\n-`void git_die_config_linenr(const char *key, const char *filename, int linenr)`::\n-\n-\tHelper function which formats the die error message according to the\n-\tparameters entered. Used by `git_die_config()`. It can be used by callers\n-\thandling `git_config_get_value_multi()` to print the correct error message\n-\tfor the desired value.\n-\n-See test-config.c for usage examples.\n-\n-Value Parsing Helpers\n----------------------\n-\n-To aid in parsing string values, the config API provides callbacks with\n-a number of helper functions, including:\n-\n-`git_config_int`::\n-Parse the string to an integer, including unit factors. Dies on error;\n-otherwise, returns the parsed result.\n-\n-`git_config_ulong`::\n-Identical to `git_config_int`, but for unsigned longs.\n-\n-`git_config_bool`::\n-Parse a string into a boolean value, respecting keywords like \"true\" and\n-\"false\". Integer values are converted into true/false values (when they\n-are non-zero or zero, respectively). Other values cause a die(). If\n-parsing is successful, the return value is the result.\n-\n-`git_config_bool_or_int`::\n-Same as `git_config_bool`, except that integers are returned as-is, and\n-an `is_bool` flag is unset.\n-\n-`git_parse_maybe_bool`::\n-Same as `git_config_bool`, except that it returns -1 on error rather\n-than dying.\n-\n-`git_config_string`::\n-Allocates and copies the value string into the `dest` parameter; if no\n-string is given, prints an error message and returns -1.\n-\n-`git_config_pathname`::\n-Similar to `git_config_string`, but expands `~` or `~user` into the\n-user's home directory when found at the beginning of the path.\n-\n-Include Directives\n-------------------\n-\n-By default, the config parser does not respect include directives.\n-However, a caller can use the special `git_config_include` wrapper\n-callback to support them. To do so, you simply wrap your \"real\" callback\n-function and data pointer in a `struct config_include_data`, and pass\n-the wrapper to the regular config-reading functions. For example:\n-\n--------------------------------------------\n-int read_file_with_include(const char *file, config_fn_t fn, void *data)\n-{\n-\tstruct config_include_data inc = CONFIG_INCLUDE_INIT;\n-\tinc.fn = fn;\n-\tinc.data = data;\n-\treturn git_config_from_file(git_config_include, file, &inc);\n-}\n--------------------------------------------\n-\n-`git_config` respects includes automatically. The lower-level\n-`git_config_from_file` does not.\n-\n-Custom Configsets\n------------------\n-\n-A `config_set` can be used to construct an in-memory cache for\n-config-like files that the caller specifies (i.e., files like `.gitmodules`,\n-`~/.gitconfig` etc.). For example,\n-\n-----------------------------------------\n-struct config_set gm_config;\n-git_configset_init(&gm_config);\n-int b;\n-/* we add config files to the config_set */\n-git_configset_add_file(&gm_config, \".gitmodules\");\n-git_configset_add_file(&gm_config, \".gitmodules_alt\");\n-\n-if (!git_configset_get_bool(gm_config, \"submodule.frotz.ignore\", &b)) {\n-\t/* hack hack hack */\n-}\n-\n-/* when we are done with the configset */\n-git_configset_clear(&gm_config);\n-----------------------------------------\n-\n-Configset API provides functions for the above mentioned work flow, including:\n-\n-`void git_configset_init(struct config_set *cs)`::\n-\n-\tInitializes the config_set `cs`.\n-\n-`int git_configset_add_file(struct config_set *cs, const char *filename)`::\n-\n-\tParses the file and adds the variable-value pairs to the `config_set`,\n-\tdies if there is an error in parsing the file. Returns 0 on success, or\n-\t-1 if the file does not exist or is inaccessible. The user has to decide\n-\tif he wants to free the incomplete configset or continue using it when\n-\tthe function returns -1.\n-\n-`int git_configset_get_value(struct config_set *cs, const char *key, const char **value)`::\n-\n-\tFinds the highest-priority value for the configuration variable `key`\n-\tand config set `cs`, stores the pointer to it in `value` and returns 0.\n-\tWhen the configuration variable `key` is not found, returns 1 without\n-\ttouching `value`. The caller should not free or modify `value`, as it\n-\tis owned by the cache.\n-\n-`const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key)`::\n-\n-\tFinds and returns the value list, sorted in order of increasing priority\n-\tfor the configuration variable `key` and config set `cs`. When the\n-\tconfiguration variable `key` is not found, returns NULL. The caller\n-\tshould not free or modify the returned pointer, as it is owned by the cache.\n-\n-`void git_configset_clear(struct config_set *cs)`::\n-\n-\tClears `config_set` structure, removes all saved variable-value pairs.\n-\n-In addition to above functions, the `config_set` API provides type specific\n-functions in the vein of `git_config_get_int` and family but with an extra\n-parameter, pointer to struct `config_set`.\n-They all behave similarly to the `git_config_get*()` family described in\n-\"Querying For Specific Variables\" above.\n-\n-Writing Config Files\n---------------------\n-\n-Git gives multiple entry points in the Config API to write config values to\n-files namely `git_config_set_in_file` and `git_config_set`, which write to\n-a specific config file or to `.git/config` respectively. They both take a\n-key/value pair as parameter.\n-In the end they both call `git_config_set_multivar_in_file` which takes four\n-parameters:\n-\n-- the name of the file, as a string, to which key/value pairs will be written.\n-\n-- the name of key, as a string. This is in canonical \"flat\" form: the section,\n- subsection, and variable segments will be separated by dots, and the section\n- and variable segments will be all lowercase.\n- E.g., `core.ignorecase`, `diff.SomeType.textconv`.\n-\n-- the value of the variable, as a string. If value is equal to NULL, it will\n- remove the matching key from the config file.\n-\n-- the value regex, as a string. It will disregard key/value pairs where value\n- does not match.\n-\n-- a multi_replace value, as an int. If value is equal to zero, nothing or only\n- one matching key/value is replaced, else all matching key/values (regardless\n- how many) are removed, before the new pair is written.\n-\n-It returns 0 on success.\n-\n-Also, there are functions `git_config_rename_section` and\n-`git_config_rename_section_in_file` with parameters `old_name` and `new_name`\n-for renaming or removing sections in the config files. If NULL is passed\n-through `new_name` parameter, the section will be removed from the config file.\ndiff --git a/config.h b/config.h\nindex f0ed464004..91fd4c5e96 100644\n--- a/config.h\n+++ b/config.h\n@@ -4,6 +4,22 @@\n #include \"hashmap.h\"\n #include \"string-list.h\"\n \n+\n+/**\n+ * The config API gives callers a way to access Git configuration files\n+ * (and files which have the same syntax).\n+ *\n+ * General Usage\n+ * -------------\n+ *\n+ * Config files are parsed linearly, and each variable found is passed to a\n+ * caller-provided callback function. The callback function is responsible\n+ * for any actions to be taken on the config option, and is free to ignore\n+ * some options. It is not uncommon for the configuration to be parsed\n+ * several times during the run of a Git program, with different callbacks\n+ * picking out different variables useful to themselves.\n+ */\n+\n struct object_id;\n \n /* git_config_parse_key() returns these negated: */\n@@ -71,9 +87,34 @@ struct config_options {\n \t} error_action;\n };\n \n+/**\n+ * A config callback function takes three parameters:\n+ *\n+ * - the name of the parsed variable. This is in canonical \"flat\" form: the\n+ * section, subsection, and variable segments will be separated by dots,\n+ * and the section and variable segments will be all lowercase. E.g.,\n+ * `core.ignorecase`, `diff.SomeType.textconv`.\n+ *\n+ * - the value of the found variable, as a string. If the variable had no\n+ * value specified, the value will be NULL (typically this means it\n+ * should be interpreted as boolean true).\n+ *\n+ * - a void pointer passed in by the caller of the config API; this can\n+ * contain callback-specific data\n+ *\n+ * A config callback should return 0 for success, or -1 if the variable\n+ * could not be parsed properly.\n+ */\n typedef int (*config_fn_t)(const char *, const char *, void *);\n+\n int git_default_config(const char *, const char *, void *);\n+\n+/**\n+ * Read a specific file in git-config format.\n+ * This function takes the same callback and data parameters as `git_config`.\n+ */\n int git_config_from_file(config_fn_t fn, const char *, void *);\n+\n int git_config_from_file_with_options(config_fn_t fn, const char *,\n \t\t\t\t void *,\n \t\t\t\t const struct config_options *);\n@@ -88,34 +129,157 @@ void git_config_push_parameter(const char *text);\n int git_config_from_parameters(config_fn_t fn, void *data);\n void read_early_config(config_fn_t cb, void *data);\n void read_very_early_config(config_fn_t cb, void *data);\n+\n+/**\n+ * Most programs will simply want to look up variables in all config files\n+ * that Git knows about, using the normal precedence rules. To do this,\n+ * call `git_config` with a callback function and void data pointer.\n+ *\n+ * `git_config` will read all config sources in order of increasing\n+ * priority. Thus a callback should typically overwrite previously-seen\n+ * entries with new ones (e.g., if both the user-wide `~/.gitconfig` and\n+ * repo-specific `.git/config` contain `color.ui`, the config machinery\n+ * will first feed the user-wide one to the callback, and then the\n+ * repo-specific one; by overwriting, the higher-priority repo-specific\n+ * value is left at the end).\n+ */\n void git_config(config_fn_t fn, void *);\n+\n+/**\n+ * Lets the caller examine config while adjusting some of the default\n+ * behavior of `git_config`. It should almost never be used by \"regular\"\n+ * Git code that is looking up configuration variables.\n+ * It is intended for advanced callers like `git-config`, which are\n+ * intentionally tweaking the normal config-lookup process.\n+ * It takes two extra parameters:\n+ *\n+ * - `config_source`\n+ * If this parameter is non-NULL, it specifies the source to parse for\n+ * configuration, rather than looking in the usual files. See `struct\n+ * git_config_source` in `config.h` for details. Regular `git_config` defaults\n+ * to `NULL`.\n+ *\n+ * - `opts`\n+ * Specify options to adjust the behavior of parsing config files. See `struct\n+ * config_options` in `config.h` for details. As an example: regular `git_config`\n+ * sets `opts.respect_includes` to `1` by default.\n+ */\n int config_with_options(config_fn_t fn, void *,\n \t\t\tstruct git_config_source *config_source,\n \t\t\tconst struct config_options *opts);\n+\n+/**\n+ * Value Parsing Helpers\n+ * ---------------------\n+ *\n+ * The following helper functions aid in parsing string values\n+ */\n+\n int git_parse_ssize_t(const char *, ssize_t *);\n int git_parse_ulong(const char *, unsigned long *);\n+\n+/**\n+ * Same as `git_config_bool`, except that it returns -1 on error rather\n+ * than dying.\n+ */\n int git_parse_maybe_bool(const char *);\n+\n+/**\n+ * Parse the string to an integer, including unit factors. Dies on error;\n+ * otherwise, returns the parsed result.\n+ */\n int git_config_int(const char *, const char *);\n+\n int64_t git_config_int64(const char *, const char *);\n+\n+/**\n+ * Identical to `git_config_int`, but for unsigned longs.\n+ */\n unsigned long git_config_ulong(const char *, const char *);\n+\n ssize_t git_config_ssize_t(const char *, const char *);\n+\n+/**\n+ * Same as `git_config_bool`, except that integers are returned as-is, and\n+ * an `is_bool` flag is unset.\n+ */\n int git_config_bool_or_int(const char *, const char *, int *);\n+\n+/**\n+ * Parse a string into a boolean value, respecting keywords like \"true\" and\n+ * \"false\". Integer values are converted into true/false values (when they\n+ * are non-zero or zero, respectively). Other values cause a die(). If\n+ * parsing is successful, the return value is the result.\n+ */\n int git_config_bool(const char *, const char *);\n+\n+/**\n+ * Allocates and copies the value string into the `dest` parameter; if no\n+ * string is given, prints an error message and returns -1.\n+ */\n int git_config_string(const char **, const char *, const char *);\n+\n+/**\n+ * Similar to `git_config_string`, but expands `~` or `~user` into the\n+ * user's home directory when found at the beginning of the path.\n+ */\n int git_config_pathname(const char **, const char *, const char *);\n+\n int git_config_expiry_date(timestamp_t *, const char *, const char *);\n int git_config_color(char *, const char *, const char *);\n int git_config_set_in_file_gently(const char *, const char *, const char *);\n+\n+/**\n+ * write config values to a specific config file, takes a key/value pair as\n+ * parameter.\n+ */\n void git_config_set_in_file(const char *, const char *, const char *);\n+\n int git_config_set_gently(const char *, const char *);\n+\n+/**\n+ * write config values to `.git/config`, takes a key/value pair as parameter.\n+ */\n void git_config_set(const char *, const char *);\n+\n int git_config_parse_key(const char *, char **, int *);\n int git_config_key_is_valid(const char *key);\n int git_config_set_multivar_gently(const char *, const char *, const char *, int);\n void git_config_set_multivar(const char *, const char *, const char *, int);\n int git_config_set_multivar_in_file_gently(const char *, const char *, const char *, const char *, int);\n+\n+/**\n+ * takes four parameters:\n+ *\n+ * - the name of the file, as a string, to which key/value pairs will be written.\n+ *\n+ * - the name of key, as a string. This is in canonical \"flat\" form: the section,\n+ * subsection, and variable segments will be separated by dots, and the section\n+ * and variable segments will be all lowercase.\n+ * E.g., `core.ignorecase`, `diff.SomeType.textconv`.\n+ *\n+ * - the value of the variable, as a string. If value is equal to NULL, it will\n+ * remove the matching key from the config file.\n+ *\n+ * - the value regex, as a string. It will disregard key/value pairs where value\n+ * does not match.\n+ *\n+ * - a multi_replace value, as an int. If value is equal to zero, nothing or only\n+ * one matching key/value is replaced, else all matching key/values (regardless\n+ * how many) are removed, before the new pair is written.\n+ *\n+ * It returns 0 on success.\n+ */\n void git_config_set_multivar_in_file(const char *, const char *, const char *, const char *, int);\n+\n+/**\n+ * rename or remove sections in the config file\n+ * parameters `old_name` and `new_name`\n+ * If NULL is passed through `new_name` parameter,\n+ * the section will be removed from the config file.\n+ */\n int git_config_rename_section(const char *, const char *);\n+\n int git_config_rename_section_in_file(const char *, const char *, const char *);\n int git_config_copy_section(const char *, const char *);\n int git_config_copy_section_in_file(const char *, const char *, const char *);\n@@ -142,6 +306,30 @@ enum config_scope current_config_scope(void);\n const char *current_config_origin_type(void);\n const char *current_config_name(void);\n \n+/**\n+ * Include Directives\n+ * ------------------\n+ *\n+ * By default, the config parser does not respect include directives.\n+ * However, a caller can use the special `git_config_include` wrapper\n+ * callback to support them. To do so, you simply wrap your \"real\" callback\n+ * function and data pointer in a `struct config_include_data`, and pass\n+ * the wrapper to the regular config-reading functions. For example:\n+ *\n+ * -------------------------------------------\n+ * int read_file_with_include(const char *file, config_fn_t fn, void *data)\n+ * {\n+ * struct config_include_data inc = CONFIG_INCLUDE_INIT;\n+ * inc.fn = fn;\n+ * inc.data = data;\n+ * return git_config_from_file(git_config_include, file, &inc);\n+ * }\n+ * -------------------------------------------\n+ *\n+ * `git_config` respects includes automatically. The lower-level\n+ * `git_config_from_file` does not.\n+ *\n+ */\n struct config_include_data {\n \tint depth;\n \tconfig_fn_t fn;\n@@ -169,6 +357,33 @@ int parse_config_key(const char *var,\n \t\t const char **subsection, int *subsection_len,\n \t\t const char **key);\n \n+/**\n+ * Custom Configsets\n+ * -----------------\n+ *\n+ * A `config_set` can be used to construct an in-memory cache for\n+ * config-like files that the caller specifies (i.e., files like `.gitmodules`,\n+ * `~/.gitconfig` etc.). For example,\n+ *\n+ * ----------------------------------------\n+ * struct config_set gm_config;\n+ * git_configset_init(&gm_config);\n+ * int b;\n+ * //we add config files to the config_set\n+ * git_configset_add_file(&gm_config, \".gitmodules\");\n+ * git_configset_add_file(&gm_config, \".gitmodules_alt\");\n+ *\n+ * if (!git_configset_get_bool(gm_config, \"submodule.frotz.ignore\", &b)) {\n+ * //hack hack hack\n+ * }\n+ *\n+ * when we are done with the configset:\n+ * git_configset_clear(&gm_config);\n+ * ----------------------------------------\n+ *\n+ * Configset API provides functions for the above mentioned work flow\n+ */\n+\n struct config_set_element {\n \tstruct hashmap_entry ent;\n \tchar *key;\n@@ -197,16 +412,47 @@ struct config_set {\n \tstruct configset_list list;\n };\n \n+/**\n+ * Initializes the config_set `cs`.\n+ */\n void git_configset_init(struct config_set *cs);\n+\n+/**\n+ * Parses the file and adds the variable-value pairs to the `config_set`,\n+ * dies if there is an error in parsing the file. Returns 0 on success, or\n+ * -1 if the file does not exist or is inaccessible. The user has to decide\n+ * if he wants to free the incomplete configset or continue using it when\n+ * the function returns -1.\n+ */\n int git_configset_add_file(struct config_set *cs, const char *filename);\n+\n+/**\n+ * Finds and returns the value list, sorted in order of increasing priority\n+ * for the configuration variable `key` and config set `cs`. When the\n+ * configuration variable `key` is not found, returns NULL. The caller\n+ * should not free or modify the returned pointer, as it is owned by the cache.\n+ */\n const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key);\n+\n+/**\n+ * Clears `config_set` structure, removes all saved variable-value pairs.\n+ */\n void git_configset_clear(struct config_set *cs);\n \n /*\n * These functions return 1 if not found, and 0 if found, leaving the found\n * value in the 'dest' pointer.\n */\n+\n+/*\n+ * Finds the highest-priority value for the configuration variable `key`\n+ * and config set `cs`, stores the pointer to it in `value` and returns 0.\n+ * When the configuration variable `key` is not found, returns 1 without\n+ * touching `value`. The caller should not free or modify `value`, as it\n+ * is owned by the cache.\n+ */\n int git_configset_get_value(struct config_set *cs, const char *key, const char **dest);\n+\n int git_configset_get_string_const(struct config_set *cs, const char *key, const char **dest);\n int git_configset_get_string(struct config_set *cs, const char *key, char **dest);\n int git_configset_get_int(struct config_set *cs, const char *key, int *dest);\n@@ -240,17 +486,94 @@ int repo_config_get_maybe_bool(struct repository *repo,\n int repo_config_get_pathname(struct repository *repo,\n \t\t\t const char *key, const char **dest);\n \n+/**\n+ * Querying For Specific Variables\n+ * -------------------------------\n+ *\n+ * For programs wanting to query for specific variables in a non-callback\n+ * manner, the config API provides two functions `git_config_get_value`\n+ * and `git_config_get_value_multi`. They both read values from an internal\n+ * cache generated previously from reading the config files.\n+ */\n+\n+/**\n+ * Finds the highest-priority value for the configuration variable `key`,\n+ * stores the pointer to it in `value` and returns 0. When the\n+ * configuration variable `key` is not found, returns 1 without touching\n+ * `value`. The caller should not free or modify `value`, as it is owned\n+ * by the cache.\n+ */\n int git_config_get_value(const char *key, const char **value);\n+\n+/**\n+ * Finds and returns the value list, sorted in order of increasing priority\n+ * for the configuration variable `key`. When the configuration variable\n+ * `key` is not found, returns NULL. The caller should not free or modify\n+ * the returned pointer, as it is owned by the cache.\n+ */\n const struct string_list *git_config_get_value_multi(const char *key);\n+\n+/**\n+ * Resets and invalidates the config cache.\n+ */\n void git_config_clear(void);\n+\n+/**\n+ * Allocates and copies the retrieved string into the `dest` parameter for\n+ * the configuration variable `key`; if NULL string is given, prints an\n+ * error message and returns -1. When the configuration variable `key` is\n+ * not found, returns 1 without touching `dest`.\n+ */\n int git_config_get_string_const(const char *key, const char **dest);\n+\n+/**\n+ * Similar to `git_config_get_string_const`, except that retrieved value\n+ * copied into the `dest` parameter is a mutable string.\n+ */\n int git_config_get_string(const char *key, char **dest);\n+\n+/**\n+ * Finds and parses the value to an integer for the configuration variable\n+ * `key`. Dies on error; otherwise, stores the value of the parsed integer in\n+ * `dest` and returns 0. When the configuration variable `key` is not found,\n+ * returns 1 without touching `dest`.\n+ */\n int git_config_get_int(const char *key, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_int` but for unsigned longs.\n+ */\n int git_config_get_ulong(const char *key, unsigned long *dest);\n+\n+/**\n+ * Finds and parses the value into a boolean value, for the configuration\n+ * variable `key` respecting keywords like \"true\" and \"false\". Integer\n+ * values are converted into true/false values (when they are non-zero or\n+ * zero, respectively). Other values cause a die(). If parsing is successful,\n+ * stores the value of the parsed result in `dest` and returns 0. When the\n+ * configuration variable `key` is not found, returns 1 without touching\n+ * `dest`.\n+ */\n int git_config_get_bool(const char *key, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_bool`, except that integers are copied as-is,\n+ * and `is_bool` flag is unset.\n+ */\n int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_bool`, except that it returns -1 on error\n+ * rather than dying.\n+ */\n int git_config_get_maybe_bool(const char *key, int *dest);\n+\n+/**\n+ * Similar to `git_config_get_string`, but expands `~` or `~user` into\n+ * the user's home directory when found at the beginning of the path.\n+ */\n int git_config_get_pathname(const char *key, const char **dest);\n+\n int git_config_get_index_threads(int *dest);\n int git_config_get_untracked_cache(void);\n int git_config_get_split_index(void);\n@@ -270,7 +593,19 @@ struct key_value_info {\n \tenum config_scope scope;\n };\n \n+/**\n+ * First prints the error message specified by the caller in `err` and then\n+ * dies printing the line number and the file name of the highest priority\n+ * value for the configuration variable `key`.\n+ */\n NORETURN void git_die_config(const char *key, const char *err, ...) __attribute__((format(printf, 2, 3)));\n+\n+/**\n+ * Helper function which formats the die error message according to the\n+ * parameters entered. Used by `git_die_config()`. It can be used by callers\n+ * handling `git_config_get_value_multi()` to print the correct error message\n+ * for the desired value.\n+ */\n NORETURN void git_die_config_linenr(const char *key, const char *filename, int linenr);\n \n #define LOOKUP_CONFIG(mapping, var) \\\n-- \ngitgitgadget\n"},{"id":"384724","messageId":"20191023213834.GA124161@google.com","threadId":"52062","inReplyTo":"d6cbb3197af2c59f0222c7806ab6a6fcdf83869a.1571808652.git.gitgitgadget@gmail.com","subject":"Re: [PATCH v3 1/1] config: move documentation to config.h","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-23T21:38:34Z","receivedAt":"2019-10-23T21:38:42Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Wed, Oct 23, 2019 at 05:30:52AM +0000, Heba Waly via GitGitGadget wrote:\n> From: Heba Waly \n> \n> Move the documentation from Documentation/technical/api-config.txt into\n> config.h as it's easier for the developers to find the usage information\n> beside the code instead of looking for it in another doc file, also\n> documentation/technical/api-config.txt is removed because the information\n> it has is now redundant and it'll be hard to keep it up to date and\n> syncronized with the documentation in config.h\n> \n> Signed-off-by: Heba Waly \n\nReviewed-by: Emily Shaffer \n\nThanks for the effort, Heba. (I guess you are an expert on git-config\nnow!)\n\n - Emily\n"},{"id":"384740","messageId":"xmqqeez2hoty.fsf@gitster-ct.c.googlers.com","threadId":"52062","inReplyTo":"20191023213834.GA124161@google.com","subject":"Re: [PATCH v3 1/1] config: move documentation to config.h","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-10-24T02:14:33Z","receivedAt":"2019-10-24T02:14:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emily Shaffer writes:\n\n> On Wed, Oct 23, 2019 at 05:30:52AM +0000, Heba Waly via GitGitGadget wrote:\n>> From: Heba Waly \n>> \n>> Move the documentation from Documentation/technical/api-config.txt into\n>> config.h as it's easier for the developers to find the usage information\n>> beside the code instead of looking for it in another doc file, also\n>> documentation/technical/api-config.txt is removed because the information\n>> it has is now redundant and it'll be hard to keep it up to date and\n>> syncronized with the documentation in config.h\n>> \n>> Signed-off-by: Heba Waly \n>\n> Reviewed-by: Emily Shaffer \n>\n> Thanks for the effort, Heba. (I guess you are an expert on git-config\n> now!)\n\nThanks, both. Will queue.\n"}]}