path: root/builtin/config.c
AgeCommit message (Collapse)Author
2015-09-25config: use xstrfmt in normalize_valueJeff King
We xmalloc a fixed-size buffer and sprintf into it; this is OK because the size of our formatting types is finite, but that's not immediately clear to a reader auditing sprintf calls. Let's switch to xstrfmt, which is shorter and obviously correct. Note that just dropping the common xmalloc here causes gcc to complain with -Wmaybe-uninitialized. That's because if "types" does not match any of our known types, we never write anything into the "normalized" pointer. With the current code, gcc doesn't notice because we always return a valid pointer (just one which might point to uninitialized data, but the compiler doesn't know that). In other words, the current code is potentially buggy if new types are added without updating this spot. So let's take this opportunity to clean up the function a bit more. We can drop the "normalized" pointer entirely, and just return directly from each code path. And then add an assertion at the end in case we haven't covered any cases. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-08-20get_urlmatch: avoid useless strbuf writeJeff King
We create a strbuf only to insert a single string, pass the resulting buffer to a function (which does not modify the string), and then free it. We can just pass the original string instead. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-08-20format_config: simplify buffer handlingJeff King
When formatting a config value into a strbuf, we may end up stringifying it into a fixed-size buffer using sprintf, and then copying that buffer into the strbuf. We can eliminate the middle-man (and drop some calls to sprintf!) by writing directly to the strbuf. The reason it was written this way in the first place is that we need to know before writing the value whether to insert a delimiter. Instead of delaying the write of the value, we speculatively write the delimiter, and roll it back in the single case that cares. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-08-20format_config: don't init strbufJeff King
It's unusual for a function which writes to a passed-in strbuf to call strbuf_init; that will throw away anything already there, leaking memory. In this case, there are exactly two callers; one relies on this initialization and the other passes in an already-initialized buffer. There's no leak, as the initialized buffer doesn't have anything in it. But let's bump the strbuf_init out to the one caller who needs it, making format_config more idiomatic. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-08-20config: restructure format_config() for better control flowSZEDER Gábor
Commit 578625fa91 (config: add '--name-only' option to list only variable names, 2015-08-10) modified format_config() such that it returned from the middle of the function when showing only keys, resulting in ugly code structure. Reorganize the if statements and dealing with the key-value delimiter to make the function easier to read. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2015-08-10config: add '--name-only' option to list only variable namesSZEDER Gábor
'git config' can only show values or name-value pairs, so if a shell script needs the names of set config variables it has to run 'git config --list' or '--get-regexp' and parse the output to separate config variable names from their values. However, such a parsing can't cope with multi-line values. Though 'git config' can produce null-terminated output for newline-safe parsing, that's of no use in such a case, becase shells can't cope with null characters. Even our own bash completion script suffers from these issues. Help the completion script, and shell scripts in general, by introducing the '--name-only' option to modify the output of '--list' and '--get-regexp' to list only the names of config variables, so they don't have to perform error-prone post processing to separate variable names from their values anymore. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2015-05-11Merge branch 'pt/xdg-config-path'Junio C Hamano
Code clean-up for xdg configuration path support. * pt/xdg-config-path: path.c: remove home_config_paths() git-config: replace use of home_config_paths() git-commit: replace use of home_config_paths() credential-store.c: replace home_config_paths() with xdg_config_home() dir.c: replace home_config_paths() with xdg_config_home() attr.c: replace home_config_paths() with xdg_config_home() path.c: implement xdg_config_home()
2015-05-11Merge branch 'jn/clean-use-error-not-fprintf-on-stderr'Junio C Hamano
Some error messages in "git config" were emitted without calling the usual error() facility. * jn/clean-use-error-not-fprintf-on-stderr: config: use error() instead of fprintf(stderr, ...)
2015-05-06git-config: replace use of home_config_paths()Paul Tan
Since home_config_paths() combines distinct functionality already implemented by expand_user_path() and xdg_config_home(), and hides the home config file path ~/.gitconfig. Make the code more explicit by replacing the use of home_config_paths() with expand_user_path() and xdg_config_home(). Signed-off-by: Paul Tan <> Signed-off-by: Junio C Hamano <>
2015-05-06Merge branch 'oh/fix-config-default-user-name-section'Junio C Hamano
The default $HOME/.gitconfig file created upon "git config --global" that edits it had incorrectly spelled and entries in it. * oh/fix-config-default-user-name-section: config: fix settings in default_user_config template
2015-05-04config: use error() instead of fprintf(stderr, ...)Jonathan Nieder
The die() / error() / warning() helpers put a fatal: / error: / warning: prefix in front of the error message they print describing the message's severity, which users are likely to be accustomed to seeing these days. This change will also be useful when marking the message for translation: the argument to error() includes no newline at the end, so it is less fussy for translators to translate without lines running together in the translated output. While we're here, start the error messages with a lowercase letter to match the usual typography of error messages. A quick web search and a code search at finds no scripts trying to parse these error messages, so this change should be safe. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2015-04-17config: fix settings in default_user_config templateOssi Herrala
The name (not user) and email setting should be in config section "user" and not in "core" as documented in Documentation/config.txt. Signed-off-by: Ossi Herrala <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-01-14standardize usage info string formatAlex Henrie
This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] Signed-off-by: Alex Henrie <> Reviewed-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2014-12-12Merge branch 'jk/colors-fix'Junio C Hamano
* jk/colors-fix: t4026: test "normal" color config: fix parsing of "git config --get-color some.key -1" docs: describe ANSI 256-color mode
2014-11-20config: fix parsing of "git config --get-color some.key -1"Jeff King
Most of git-config's command line options use OPT_BIT to choose an action, and then parse the non-option arguments in a context-dependent way. However, --get-color and --get-colorbool are unlike the rest of the options, in that they are OPT_STRING, taking the option name as a parameter. This generally works, because we then use the presence of those strings to set an action bit anyway. But it does mean that the option-parser will continue looking for options even after the key (because it is not a non-option; it is an argument to an option). And running: git config --get-color some.key -1 (to use "-1" as the default color spec) will barf, claiming that "-1" is not an option. Instead, we should treat --get-color and --get-colorbool as action bits, just like --add, --get, and all the other actions, and then check that the non-option arguments we got are sane. This fixes the weirdness above, and makes those two options like all the others. This "fixes" a test in t4026, which checked that feeding "-2" as a color should fail (it does fail, but prior to this patch, because parseopt barfed, not because we actually ever tried to parse the color). This also catches other errors, like: git config --get-color some.key black blue which previously silently ignored "blue" (and now will complain that you gave too many arguments). There are some possible regressions, though. We now disallow these, which currently do what you would expect: # specifying other options after the action git config --get-color some.key --file whatever # using long-arg syntax git config --get-color=some.key However, we have never advertised these in the documentation, and in fact they did not work in some older versions of git. The behavior was apparently switched as an accidental side effect of d64ec16 (git config: reorganize to use parseopt, 2009-02-21). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-11-17cmd_config(): make a copy of path obtained from git_path()Michael Haggerty
The strings returned by git_path() are recycled after a while. Make a copy of the config filename rather than holding onto the return value from git_path(). Signed-off-by: Michael Haggerty <> Signed-off-by: Junio C Hamano <>
2014-10-20Merge branch 'jn/parse-config-slot'Junio C Hamano
Code cleanup. * jn/parse-config-slot: color_parse: do not mention variable name in error message pass config slots as pointers instead of offsets
2014-10-14color_parse: do not mention variable name in error messageJeff King
Originally the color-parsing function was used only for config variables. It made sense to pass the variable name so that the die() message could be something like: $ git -c color.branch.plain=bogus branch fatal: bad color value 'bogus' for variable 'color.branch.plain' These days we call it in other contexts, and the resulting error messages are a little confusing: $ git log --pretty='%C(bogus)' fatal: bad color value 'bogus' for variable '--pretty format' $ git config --get-color bogus fatal: bad color value 'bogus' for variable 'command line' This patch teaches color_parse to complain only about the value, and then return an error code. Config callers can then propagate that up to the config parser, which mentions the variable name. Other callers can provide a custom message. After this patch these three cases now look like: $ git -c color.branch.plain=bogus branch error: invalid color value: bogus fatal: unable to parse 'color.branch.plain' from command-line config $ git log --pretty='%C(bogus)' error: invalid color value: bogus fatal: unable to parse --pretty format $ git config --get-color bogus error: invalid color value: bogus fatal: unable to parse default color value Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-09-30Merge branch 'ta/config-add-to-empty-or-true-fix' into maintJunio C Hamano
"git config --add section.var val" used to lose existing section.var whose value was an empty string. * ta/config-add-to-empty-or-true-fix: config: avoid a funny sentinel value "a^" make config --add behave correctly for empty and NULL values
2014-09-19Merge branch 'ta/config-add-to-empty-or-true-fix'Junio C Hamano
"git config --add section.var val" used to lose existing section.var whose value was an empty string. * ta/config-add-to-empty-or-true-fix: config: avoid a funny sentinel value "a^" make config --add behave correctly for empty and NULL values
2014-09-11config: avoid a funny sentinel value "a^"Jeff King
Introduce CONFIG_REGEX_NONE as a more explicit sentinel value to say "we do not want to replace any existing entry" and use it in the implementation of "git config --add". Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-09-02Merge branch 'mm/config-edit-global'Junio C Hamano
Start "git config --edit --global" from a skeletal per-user configuration file contents, instead of a total blank, when the user does not already have any. This immediately reduces the need for a later "Have you forgotten setting core.user?" and we can add more to the template as we gain more experience. * mm/config-edit-global: commit: advertise config --global --edit on guessed identity home_config_paths(): let the caller ignore xdg path config --global --edit: create a template file if needed
2014-08-18make config --add behave correctly for empty and NULL valuesTanay Abhra
Currently if we have a config file like, [foo] baz bar = and we try something like, "git config --add foo.baz roll", Git will segfault. Moreover, for "git config --add roll", it will overwrite the original value instead of appending after the existing empty value. The problem lies with the regexp used for simulating --add in `git_config_set_multivar_in_file()`, "^$", which in ideal case should not match with any string but is true for empty strings. Instead use a regexp like "a^" which can not be true for any string, empty or not. For removing the segfault add a check for NULL values in `matches()` in config.c. Signed-off-by: Tanay Abhra <> Signed-off-by: Junio C Hamano <>
2014-07-25config --global --edit: create a template file if neededMatthieu Moy
When the user has no ~/.gitconfig file, git config --global --edit used to launch an editor on an nonexistant file name. Instead, create a file with a default content before launching the editor. The template contains only commented-out entries, to save a few keystrokes for the user. If the values are guessed properly, the user will only have to uncomment the entries. Advanced users teaching newbies can create a minimalistic configuration faster for newbies. Beginners reading a tutorial advising to run "git config --global --edit" as a first step will be slightly more guided for their first contact with Git. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2014-06-16Merge branch 'jk/daemon-tolower'Junio C Hamano
* jk/daemon-tolower: daemon/config: factor out duplicate xstrdup_tolower
2014-05-23daemon/config: factor out duplicate xstrdup_tolowerJeff King
We have two implementations of the same function; let's drop that to one. We take the name from daemon.c, but the implementation (which is just slightly more efficient) from the config code. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-02-19config: teach "git config --file -" to read from the standard inputKirill A. Shutemov
The patch extends git config --file interface to allow read config from stdin. Editing stdin or setting value in stdin is an error. Include by absolute path is allowed in stdin config, but not by relative path. Signed-off-by: Kirill A. Shutemov <> Signed-off-by: Junio C Hamano <>
2014-02-19config: change git_config_with_options() interfaceKirill A. Shutemov
We're going to have more options for config source. Let's alter git_config_with_options() interface to accept struct with all source options. Signed-off-by: Kirill A. Shutemov <> Signed-off-by: Junio C Hamano <>
2014-02-19builtin/config.c: rename check_blob_write() -> check_write()Kirill A. Shutemov
The function will be reused to check for other conditions which prevent write. Signed-off-by: Kirill A. Shutemov <> Signed-off-by: Junio C Hamano <>
2013-11-12repo-config: remove deprecated alias for "git config"John Keeping
The release notes for Git 1.5.4 say that "git repo-config" will be removed in the next feature release. Since Git 2.0 is nearly here, remove it. Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2013-09-12Merge branch 'jk/config-int-range-check'Junio C Hamano
"git config" did not provide a way to set or access numbers larger than a native "int" on the platform; it now provides 64-bit signed integers on all platforms. * jk/config-int-range-check: git-config: always treat --int as 64-bit internally config: make numeric parsing errors more clear config: set errno in numeric git_parse_* functions config: properly range-check integer values config: factor out integer parsing from range checks
2013-09-09Merge branch 'jc/url-match'Junio C Hamano
Allow section.<urlpattern>.var configuration variables to be treated as a "virtual" section.var given a URL, and use the mechanism to enhance http.* configuration variables. This is a reroll of Kyle J. McKay's work. * jc/url-match: builtin/config.c: compilation fix config: "git config --get-urlmatch" parses section.<url>.key builtin/config: refactor collect_config() config: parse http.<url>.<variable> using urlmatch config: add generic callback wrapper to parse section.<url>.key config: add helper to normalize and match URLs http.c: fix parsing of http.sslCertPasswordProtected variable
2013-09-09git-config: always treat --int as 64-bit internallyJeff King
When you run "git config --int", the maximum size of integer you get depends on how git was compiled, and what it considers to be an "int". This is almost useful, because your scripts calling "git config" will behave similarly to git internally. But relying on this is dubious; you have to actually know how git treats each value internally (e.g., int versus unsigned long), which is not documented and is subject to change. And even if you know it is "unsigned long", we do not have a git-config option to match that behavior. Furthermore, you may simply be asking git to store a value on your behalf (e.g., configuration for a hook). In that case, the relevant range check has nothing at all to do with git, but rather with whatever scripting tools you are using (and git has no way of knowing what the appropriate range is there). Not only is the range check useless, but it is actively harmful, as there is no way at all for scripts to look at config variables with large values. For instance, one cannot reliably get the value of pack.packSizeLimit via git-config. On an LP64 system, git happily uses a 64-bit "unsigned long" internally to represent the value, but the script cannot read any value over 2G. Ideally, the "--int" option would simply represent an arbitrarily large integer. For practical purposes, however, a 64-bit integer is large enough, and is much easier to implement (and if somebody overflows it, we will still notice the problem, and not simply return garbage). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2013-08-09builtin/config.c: compilation fixJunio C Hamano
Do not feed a random string as the first parameter to die(); use "%s" as the format string instead. Do the same for test-urlmatch-normalization.c while saving a single pointer variable by turning a "const char *" constant string into "const char []", which is sufficient to squelch compilation warning (the compiler can see usage[] given to die() is a constant and will never have conversion specifiers that cause trouble). But for a good measure, give them the same "%s" treatment as well. Signed-off-by: Junio C Hamano <>
2013-08-07config parsing options: allow one flag multiple timesStefan Beller
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). This commit introduces a change for the users, after this patch you can pass one of the config level flags multiple times: Before: $ git config --global --global --list error: only one config file at a time. usage: ... Afterwards this will work. This is due to the following check in the code: if (use_global_config + use_system_config + use_local_config + !!given_config_file + !!given_config_blob > 1) { error("only one config file at a time."); usage_with_options(builtin_config_usage, builtin_config_options); } With OPT_BOOL instead of OPT_BOOLEAN the variables use_global_config, use_system_config, use_local_config will only have the value 0 if the command line option was not passed or 1 no matter how often the respective command line option was passed. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2013-08-05config: "git config --get-urlmatch" parses section.<url>.keyJunio C Hamano
Using the same urlmatch_config_entry() infrastructure, add a new mode "--get-urlmatch" to the "git config" command, to learn values for the "virtual" two-level variables customized for the specific URL. git config [--<type>] --get-urlmatch <section>[.<key>] <url> With <section>.<key> fully specified, the configuration data for <section>.<urlpattern>.<key> for <urlpattern> that best matches the given <url> is sought (and if not found, <section>.<key> is used) and reported. For example, with this configuration: [http] sslVerify [http ""] cookieFile = /tmp/cookie.txt sslVerify = false You would get $ git config --bool --get-urlmatch http.sslVerify true $ git config --bool --get-urlmatch http.sslVerify false With only <section> specified, you can get a list of all variables in the section with their values that apply to the given URL. E.g $ git config --get-urlmatch http http.cookiefile /tmp/cookie.txt http.sslverify false Helped-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2013-08-05builtin/config: refactor collect_config()Junio C Hamano
In order to reuse the logic to format the configuration value while honouring the requested type, split this function into two. Signed-off-by: Junio C Hamano <>
2013-08-05Replace deprecated OPT_BOOLEAN by OPT_BOOLStefan Beller
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2013-07-22Merge branch 'hv/config-from-blob'Junio C Hamano
Allow configuration data to be read from in-tree blob objects, which would help working in a bare repository and submodule updates. * hv/config-from-blob: do not die when error in config parsing of buf occurs teach config --blob option to parse config from database config: make parsing stack struct independent from actual data source config: drop cf validity check in get_next_char() config: factor out config file stack management
2013-07-12teach config --blob option to parse config from databaseHeiko Voigt
This can be used to read configuration values directly from git's database. For example it is useful for reading to be checked out .gitmodules files directly from the database. Signed-off-by: Heiko Voigt <> Acked-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2013-06-20Merge branch 'mm/color-auto-default'Junio C Hamano
Flip the default for color.ui to 'auto', which is what many tutorials recommend new users to do. * mm/color-auto-default: make color.ui default to 'auto' config: refactor management of color.ui's default value
2013-06-10make color.ui default to 'auto'Matthieu Moy
Most users seem to like having colors enabled, and colors can help beginners to understand the output of some commands (e.g. notice immediately the boundary between commits in the output of "git log"). Many tutorials tell the users to set color.ui=auto as a very first step, which tend to indicate that color.ui=none is not the recommanded value, hence should not be the default. These tutorials would benefit from skipping this step and starting the real Git manipulations earlier. Other beginners do not know about color.ui=auto, and may not discover it by themselves, hence live with black&white outputs while they may have preferred colors. A few people (e.g. color-blind) prefer having no colors, but they can easily set color.ui=never for this (and googling "disable colors in git" already tells them how to do so), but this needs not occupy space in beginner-oriented documentations. A transition period with Git emitting a warning when color.ui is unset would be possible, but the discomfort of having the warning seems superior to the benefit: users may be surprised by the change, but not harmed by it. The default value is changed, and the documentation is reworded to mention "color.ui=false" first, since the primary use of color.ui after this change is to disable colors, not to enable it. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2013-05-15config: refactor management of color.ui's default valueMatthieu Moy
The meaning of get_colorbool_found and get_diff_color_found is "the config value if found, and -1 otherwise", but get_color_ui_found had a slightly different meaning, as it has the value 0 (which corresponds to the default value from the user point of view) when color.ui is unset. Make get_color_ui_found default to -1, and make it explicit that 0 is the default value when nothing else is found. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2013-04-15config: allow inaccessible configuration under $HOMEJonathan Nieder
The changes v1.7.12.1~2^2~4 (config: warn on inaccessible files, 2012-08-21) and v1.8.1.1~22^2~2 (config: treat user and xdg config permission problems as errors, 2012-10-13) were intended to prevent important configuration (think "[transfer] fsckobjects") from being ignored when the configuration is unintentionally unreadable (for example with EIO on a flaky filesystem, or with ENOMEM due to a DoS attack). Usually ~/.gitconfig and ~/.config/git are readable by the current user, and if they aren't then it would be easy to fix those permissions, so the damage from adding this check should have been minimal. Unfortunately the access() check often trips when git is being run as a server. A daemon (such as inetd or git-daemon) starts as "root", creates a listening socket, and then drops privileges, meaning that when git commands are invoked they cannot access $HOME and die with fatal: unable to access '/root/.config/git/config': Permission denied Any patch to fix this would have one of three problems: 1. We annoy sysadmins who need to take an extra step to handle HOME when dropping privileges (the current behavior, or any other proposal that they have to opt into). 2. We annoy sysadmins who want to set HOME when dropping privileges, either by making what they want to do impossible, or making them set an extra variable or option to accomplish what used to work (e.g., a patch to git-daemon to set HOME when --user is passed). 3. We loosen the check, so some cases which might be noteworthy are not caught. This patch is of type (3). Treat user and xdg configuration that are inaccessible due to permissions (EACCES) as though no user configuration was provided at all. An alternative method would be to check if $HOME is readable, but that would not help in cases where the user who dropped privileges had a globally readable HOME with only .config or .gitconfig being private. This does not change the behavior when /etc/gitconfig or .git/config is unreadable (since those are more serious configuration errors), nor when ~/.gitconfig or ~/.config/git is unreadable due to problems other than permissions. Signed-off-by: Jonathan Nieder <> Improved-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-11-21Merge branch 'jk/config-ignore-duplicates'Junio C Hamano
Drop duplicate detection from "git-config --get"; this lets it better match the internal config callbacks, which clears up some corner cases with includes. * jk/config-ignore-duplicates: builtin/config.c: Fix a sparse warning git-config: use git_config_with_options git-config: do not complain about duplicate entries git-config: collect values instead of immediately printing git-config: fix regexp memory leaks on error conditions git-config: remove memory leak of key regexp t1300: test "git config --get-all" more thoroughly t1300: remove redundant test t1300: style updates
2012-11-20Merge branch 'cn/config-missing-path'Junio C Hamano
"git config --path $key" segfaulted on "[section] key" (a boolean "true" spelled without "=", not "[section] key = true"). * cn/config-missing-path: config: don't segfault when given --path with a missing value
2012-11-16config: don't segfault when given --path with a missing valueCarlos Martín Nieto
When given a variable without a value, such as '[section] var' and asking git-config to treat it as a path, git_config_pathname returns an error and doesn't modify its output parameter. show_config assumes that the call is always successful and sets a variable to indicate that vptr should be freed. In case of an error however, trying to do this will cause the program to be killed, as it's pointing to memory in the stack. Detect the error and return immediately to avoid freeing or accessing the uninitialed memory in the stack. Signed-off-by: Carlos Martín Nieto <> Acked-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-10-29builtin/config.c: Fix a sparse warningRamsay Jones
Sparse issues an "Using plain integer as NULL pointer" warning while checking a 'struct strbuf_list' initializer expression. The initial field of the struct has pointer type, but the initializer expression is given as '{0}'. In order to suppress the warning, we simply replace the initializer with '{NULL}'. Signed-off-by: Ramsay Jones <> Signed-off-by: Jeff King <>
2012-10-24git-config: use git_config_with_optionsJeff King
The git-config command has always implemented its own file lookup and parsing order. This was necessary because its duplicate-entry handling did not match the way git's internal callbacks worked. Now that this is no longer the case, we are free to reuse the existing parsing code. This saves us a few lines of code, but most importantly, it means that the logic for which files are examined is contained only in one place and cannot diverge. Signed-off-by: Jeff King <>
2012-10-24git-config: do not complain about duplicate entriesJeff King
If git-config is asked for a single value, it will complain and exit with an error if it finds multiple instances of that value. This is unlike the usual internal config parsing, however, which will generally overwrite previous values, leaving only the final one. For example: [set a multivar] $ git config $ git config --add [use the internal parser to fetch it] $ git var GIT_AUTHOR_IDENT Your Name <> ... [use git-config to fetch it] $ git config error: More than one value for the key This overwriting behavior is critical for the regular parser, which starts with the lowest-priority file (e.g., /etc/gitconfig) and proceeds to the highest-priority file ($GIT_DIR/config). Overwriting yields the highest priority value at the end. Git-config solves this problem by implementing its own parsing. It goes from highest to lowest priorty, but does not proceed to the next file if it has seen a value. So in practice, this distinction never mattered much, because it only triggered for values in the same file. And there was not much point in doing that; the real value is in overwriting values from lower-priority files. However, this changed with the implementation of config include files. Now we might see an include overriding a value from the parent file, which is a sensible thing to do, but git-config will flag as a duplication. This patch drops the duplicate detection for git-config and switches to a pure-overwrite model (for the single case; --get-all can still be used if callers want to do something more fancy). As is shown by the modifications to the test suite, this is a user-visible change in behavior. An alternative would be to just change the include case, but this is much cleaner for a few reasons: 1. If you change the include case, then to what? If you just stop parsing includes after getting a value, then you will get a _different_ answer than the regular config parser (you'll get the first value instead of the last value). So you'd want to implement overwrite semantics anyway. 2. Even though it is a change in behavior for git-config, it is bringing us in line with what the internal parsers already do. 3. The file-order reimplementation is the only thing keeping us from sharing more code with the internal config parser, which will help keep differences to a minimum. Going under the assumption that the primary purpose of git-config is to behave identically to how git's internal parsing works, this change can be seen as a bug-fix. Signed-off-by: Jeff King <>