path: root/builtin/config.c
AgeCommit message (Collapse)Author
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 <>
2012-10-24git-config: collect values instead of immediately printingJeff King
This is a refactor that will allow us to more easily tweak the behavior for multi-valued variables, and it will ultimately allow us to remove a lot git-config's custom code in favor of the regular git_config code. It does mean we're no longer streaming, and we're storing more in memory for the --get-all case, but in practice it is a tiny amount of data, and the results are instantaneous. Signed-off-by: Jeff King <>
2012-10-24git-config: fix regexp memory leaks on error conditionsJeff King
The get_value function has a goto label for cleaning up on errors, but it only cleans up half of what the function might allocate. Let's also clean up the key and regexp variables there. Note that we need to take special care when compiling the regex fails to clean it up ourselves, since it is in a half-constructed state (we would want to free it, but not regfree it). Similarly, we fix git_config_parse_key to return NULL when it fails, not a pointer to some already-freed memory. Signed-off-by: Jeff King <>
2012-10-24git-config: remove memory leak of key regexpJeff King
This is only called once per invocation, so it's not a major leak, but it's easy to fix. Signed-off-by: Jeff King <>
2012-09-07Merge branch 'nd/i18n-parseopt-help'Junio C Hamano
A lot of i18n mark-up for the help text from "git <cmd> -h". * nd/i18n-parseopt-help: (66 commits) Use imperative form in help usage to describe an action Reduce translations by using same terminologies i18n: write-tree: mark parseopt strings for translation i18n: verify-tag: mark parseopt strings for translation i18n: verify-pack: mark parseopt strings for translation i18n: update-server-info: mark parseopt strings for translation i18n: update-ref: mark parseopt strings for translation i18n: update-index: mark parseopt strings for translation i18n: tag: mark parseopt strings for translation i18n: symbolic-ref: mark parseopt strings for translation i18n: show-ref: mark parseopt strings for translation i18n: show-branch: mark parseopt strings for translation i18n: shortlog: mark parseopt strings for translation i18n: rm: mark parseopt strings for translation i18n: revert, cherry-pick: mark parseopt strings for translation i18n: rev-parse: mark parseopt strings for translation i18n: reset: mark parseopt strings for translation i18n: rerere: mark parseopt strings for translation i18n: status: mark parseopt strings for translation i18n: replace: mark parseopt strings for translation ...
2012-09-07Merge branch 'jk/config-warn-on-inaccessible-paths'Junio C Hamano
When looking for $HOME/.gitconfig etc., it is OK if we cannot read them because they do not exist, but we did not diagnose existing files that we cannot read. * jk/config-warn-on-inaccessible-paths: warn_on_inaccessible(): a helper to warn on inaccessible paths attr: warn on inaccessible attribute files gitignore: report access errors of exclude files config: warn on inaccessible files
2012-09-03Merge branch 'jc/maint-config-exit-status'Junio C Hamano
The exit status code from "git config" was way overspecified while being incorrect. Update the implementation to give the documented status for a case that was documented, and introduce a new code for "all other errors". * jc/maint-config-exit-status: config: "git config baa" should exit with status 1
2012-08-22Use imperative form in help usage to describe an actionNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-08-21config: warn on inaccessible filesJeff King
Before reading a config file, we check "!access(path, R_OK)" to make sure that the file exists and is readable. If it's not, then we silently ignore it. For the case of ENOENT, this is fine, as the presence of the file is optional. For other cases, though, it may indicate a configuration error (e.g., not having permissions to read the file). Let's print a warning in these cases to let the user know. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-08-20i18n: config: mark parseopt strings for translationNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-07-30config: "git config baa" should exit with status 1Junio C Hamano
We instead failed with an undocumented exit status 255. Also define a "catch-all" status and document it. Signed-off-by: Junio C Hamano <>
2012-07-16config: fix several access(NULL) callsMatthieu Moy
When $HOME is unset, home_config_paths fails and returns NULL pointers for user_config and xdg_config. Valgrind complains with Syscall param access(pathname) points to unaddressable byte(s). Don't call blindly access() on these variables, but test them for NULL-ness before. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2012-06-25config: write to $XDG_CONFIG_HOME/git/config file when appropriateHuynh Khoi Nguyen Nguyen
Teach git to write to $XDG_CONFIG_HOME/git/config if - it already exists, - $HOME/.gitconfig file doesn't, and - The --global option is used. Otherwise, write to $HOME/.gitconfig when the --global option is given, as before. If the user doesn't create $XDG_CONFIG_HOME/git/config, there is absolutely no change. Users can use this new file only if they want. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config will be used. Advice for users who often come back to an old version of Git: you shouldn't create this file. Signed-off-by: Huynh Khoi Nguyen Nguyen <> Signed-off-by: Valentin Duperray <> Signed-off-by: Franck Jonas <> Signed-off-by: Lucien Kong <> Signed-off-by: Thomas Nguy <> Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2012-06-25config: read (but not write) from $XDG_CONFIG_HOME/git/config fileHuynh Khoi Nguyen Nguyen
Teach git to read the "gitconfig" information from a new location, $XDG_CONFIG_HOME/git/config; this allows the user to avoid cluttering $HOME with many per-application configuration files. In the order of reading, this file comes between the global configuration file (typically $HOME/.gitconfig) and the system wide configuration file (typically /etc/gitconfig). We do not write to this new location (yet). If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config will be used. This is in line with XDG specification. If the new file does not exist, the behavior is unchanged. Signed-off-by: Huynh Khoi Nguyen Nguyen <> Signed-off-by: Valentin Duperray <> Signed-off-by: Franck Jonas <> Signed-off-by: Lucien Kong <> Signed-off-by: Thomas Nguy <> Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2012-03-28config: remove useless assignmentRené Scharfe
v1.7.9-8-g270a344 (config: stop using config_exclusive_filename) replaced config_exclusive_filename with given_config_file. In one case this resulted in a self-assignment, which is reported by clang as a warning. Remove the useless code. Signed-off-by: Rene Scharfe <> Acked-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-02-17config: add include directiveJeff King
It can be useful to split your ~/.gitconfig across multiple files. For example, you might have a "main" file which is used on many machines, but a small set of per-machine tweaks. Or you may want to make some of your config public (e.g., clever aliases) while keeping other data back (e.g., your name or other identifying information). Or you may want to include a number of config options in some subset of your repos without copying and pasting (e.g., you want to reference them from the .git/config of participating repos). This patch introduces an include directive for config files. It looks like: [include] path = /path/to/file This is syntactically backwards-compatible with existing git config parsers (i.e., they will see it as another config entry and ignore it unless you are looking up include.path). The implementation provides a "git_config_include" callback which wraps regular config callbacks. Callers can pass it to git_config_from_file, and it will transparently follow any include directives, passing all of the discovered options to the real callback. Include directives are turned on automatically for "regular" git config parsing. This includes calls to git_config, as well as calls to the "git config" program that do not specify a single file (e.g., using "-f", "--global", etc). They are not turned on in other cases, including: 1. Parsing of other config-like files, like .gitmodules. There isn't a real need, and I'd rather be conservative and avoid unnecessary incompatibility or confusion. 2. Reading single files via "git config". This is for two reasons: a. backwards compatibility with scripts looking at config-like files. b. inspection of a specific file probably means you care about just what's in that file, not a general lookup for "do we have this value anywhere at all". If that is not the case, the caller can always specify "--includes". 3. Writing files via "git config"; we want to treat include.* variables as literal items to be copied (or modified), and not expand them. So "git config --unset-all" would operate _only_ on .git/config, not any of its included files (just as it also does not operate on ~/.gitconfig). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-02-17config: stop using config_exclusive_filenameJeff King
The git-config command sometimes operates on the default set of config files (either reading from all, or writing to repo config), and sometimes operates on a specific file. In the latter case, we set the magic global config_exclusive_filename, and the code in config.c does the right thing. Instead, let's have git-config use the "advanced" variants of config.c's functions which let it specify an individual filename (or NULL for the default). This makes the code a lot more obvious, and fixes two small bugs: 1. A relative path specified by GIT_CONFIG=foo will look in the wrong directory if we have to chdir as part of repository setup. We already handle this properly for "git config -f foo", but the GIT_CONFIG lookup used config_exclusive_filename directly. By dropping to a single magic variable, the GIT_CONFIG case now just works. 2. Calling "git config -f foo --edit" would not respect core.editor. This is because just before editing, we called git_config, which would respect the config_exclusive_filename setting, even though this particular git_config call was not about looking in the user's specified file, but rather about loading actual git config, just as any other git program would. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-02-17config: copy the return value of prefix_filenameJeff King
The prefix_filename function returns a pointer to a static buffer which may be overwritten by subsequent calls. Since we are going to keep the result around for a while, let's be sure to duplicate it for safety. I don't think this can be triggered as a bug in the current code, but it's a good idea to be defensive, as any resulting bug would be quite subtle. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-12-28Merge branch 'jv/maint-config-set' into maintJunio C Hamano
* jv/maint-config-set: Fix an incorrect reference to --set-all.
2011-12-27Fix an incorrect reference to --set-all.Jelmer Vernooij
Signed-off-by: Jelmer Vernooij <> Signed-off-by: Junio C Hamano <>
2011-10-18Merge branch 'mm/maint-config-explicit-bool-display'Junio C Hamano
* mm/maint-config-explicit-bool-display: config: display key_delim for config --bool --get-regexp
2011-10-10config: display key_delim for config --bool --get-regexpMatthieu Moy
The previous logic in show_config was to print the delimiter when the value was set, but Boolean variables have an implicit value "true" when they appear with no value in the config file. As a result, we got: git_Config --get-regexp '.*\.Boolean' #1. Ok: example.boolean git_Config --bool --get-regexp '.*\.Boolean' #2. NO: example.booleantrue Fix this by defering the display of the separator until after the value to display has been computed. Reported-by: Brian Foster <> Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2011-08-19config: refactor get_colorbool functionJeff King
For "git config --get-colorbool", we use a custom callback that looks not only for the key that the user gave us, but also for "diff.color" (for backwards compatibility) and "color.ui" (as a fallback). For the former, we use a custom variable to store the diff.color value. For the latter, though, we store it in the main "git_use_color_default" variable, turning on color.ui for any other parts of git that respect this value. In practice, this doesn't cause any bugs, because git-config runs without caring about git_use_color_default, and then exits. But it crosses module boundaries in an unusual and confusing way, and it makes refactoring color handling harder than it needs to be. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-08-19color: delay auto-color decision until point of useJeff King
When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-08-18git_config_colorbool: refactor stdout_is_tty handlingJeff King
Usually this function figures out for itself whether stdout is a tty. However, it has an extra parameter just to allow git-config to override the auto-detection for its --get-colorbool option. Instead of an extra parameter, let's just use a global variable. This makes calling easier in the common case, and will make refactoring the colorbool code much simpler. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-05-18config: Give error message when not changing a multivarMichael J Gruber
When trying to set a multivar with "git config var value", "git config" issues warning: remote.repoor.push has multiple values leaving the user under the impression that the operation succeeded, unless one checks the return value. Instead, make it warning: remote.repoor.push has multiple values error: cannot overwrite multiple values with a single value Use a regexp, --add or --set-all to change remote.repoor.push. to be clear and helpful. Note: The "warning" is raised through other code paths also so that it needs to remain a warning for these (which do not raise the error). Only the caller can determine how to go on from that. Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2011-03-15config: drop support for GIT_CONFIG_NOGLOBALJonathan Nieder
Now that test-lib sets $HOME to protect against pollution from user settings, GIT_CONFIG_NOGLOBAL is not needed for use by the test suite any more. And as luck would have it, a quick code search reveals no other users in the wild. This patch does not affect GIT_CONFIG_NOSYSTEM, which is still needed. Helped-by: Jeff King <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-02-28Merge branch 'lp/config-vername-check'Junio C Hamano
* lp/config-vername-check: Disallow empty section and variable names Sanity-check config variable names
2011-02-28Merge branch 'mg/placeholders-are-lowercase'Junio C Hamano
* mg/placeholders-are-lowercase: Make <identifier> lowercase in Documentation Make <identifier> lowercase as per CodingGuidelines Make <identifier> lowercase as per CodingGuidelines Make <identifier> lowercase as per CodingGuidelines CodingGuidelines: downcase placeholders in usage messages
2011-02-22Sanity-check config variable namesLibor Pechacek
Sanity-check config variable names when adding and retrieving them. As a side effect code duplication between git_config_set_multivar and get_value (in builtin/config.c) was removed and the common functionality was placed in git_config_parse_key. This breaks a test in t1300 which used invalid section-less keys in the tests for "git -c". However, allowing such names there was useless, since there was no way to set them via config file, and no part of git actually tried to use section-less keys. This patch updates the test to use more realistic examples as well as adding its own test. Signed-off-by: Libor Pechacek <> Acked-by: Jeff King <> Signed-off-by: Junio C Hamano <>