summaryrefslogtreecommitdiff
path: root/builtin/config.c
AgeCommit message (Collapse)AuthorFilesLines
2012-09-07Merge branch 'nd/i18n-parseopt-help'Libravatar Junio C Hamano1-28/+28
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'Libravatar Junio C Hamano1-2/+2
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'Libravatar Junio C Hamano1-2/+6
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 actionLibravatar Nguyễn Thái Ngọc Duy1-4/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21config: warn on inaccessible filesLibravatar Jeff King1-2/+2
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-20i18n: config: mark parseopt strings for translationLibravatar Nguyễn Thái Ngọc Duy1-28/+28
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-30config: "git config baa" should exit with status 1Libravatar Junio C Hamano1-2/+6
We instead failed with an undocumented exit status 255. Also define a "catch-all" status and document it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-16config: fix several access(NULL) callsLibravatar Matthieu Moy1-4/+12
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 <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25config: write to $XDG_CONFIG_HOME/git/config file when appropriateLibravatar Huynh Khoi Nguyen Nguyen1-4/+1
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 <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25config: read (but not write) from $XDG_CONFIG_HOME/git/config fileLibravatar Huynh Khoi Nguyen Nguyen1-9/+19
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 <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-28config: remove useless assignmentLibravatar René Scharfe1-2/+0
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 <rene.scharfe@lsrfire.ath.cx> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17config: add include directiveLibravatar Jeff King1-10/+28
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 foo.bar" 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17config: stop using config_exclusive_filenameLibravatar Jeff King1-24/+35
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17config: copy the return value of prefix_filenameLibravatar Jeff King1-3/+4
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-28Merge branch 'jv/maint-config-set' into maintLibravatar Junio C Hamano1-1/+1
* jv/maint-config-set: Fix an incorrect reference to --set-all.
2011-12-27Fix an incorrect reference to --set-all.Libravatar Jelmer Vernooij1-1/+1
Signed-off-by: Jelmer Vernooij <jelmer@samba.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-17Merge branch 'mm/maint-config-explicit-bool-display'Libravatar Junio C Hamano1-7/+13
* 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-regexpLibravatar Matthieu Moy1-7/+13
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 <brian.foster@maxim-ic.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-19config: refactor get_colorbool functionLibravatar Jeff King1-2/+3
For "git config --get-colorbool color.foo", 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-19color: delay auto-color decision until point of useLibravatar Jeff King1-0/+2
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18git_config_colorbool: refactor stdout_is_tty handlingLibravatar Jeff King1-16/+7
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-17config: Give error message when not changing a multivarLibravatar Michael J Gruber1-1/+6
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 <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-15config: drop support for GIT_CONFIG_NOGLOBALLibravatar Jonathan Nieder1-1/+1
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 <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-27Merge branch 'lp/config-vername-check'Libravatar Junio C Hamano1-7/+20
* lp/config-vername-check: Disallow empty section and variable names Sanity-check config variable names
2011-02-27Merge branch 'mg/placeholders-are-lowercase'Libravatar Junio C Hamano1-1/+1
* 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 namesLibravatar Libor Pechacek1-7/+20
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 <lpechacek@suse.cz> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-15Make <identifier> lowercase as per CodingGuidelinesLibravatar Michael J Gruber1-1/+1
*.c part for matches with '"[A-Z]+"'. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-13repo-config: add deprecation warningLibravatar René Scharfe1-0/+6
repo-config was deprecated in 5c66d0d4 on 2008-01-17. Warn the remaining users that it has been replaced by config and is going to be removed eventually. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-31Merge branch 'jn/paginate-fix'Libravatar Junio C Hamano1-3/+2
* jn/paginate-fix: t7006 (pager): add missing TTY prerequisites merge-file: run setup_git_directory_gently() sooner var: run setup_git_directory_gently() sooner ls-remote: run setup_git_directory_gently() sooner index-pack: run setup_git_directory_gently() sooner config: run setup_git_directory_gently() sooner bundle: run setup_git_directory_gently() sooner apply: run setup_git_directory_gently() sooner grep: run setup_git_directory_gently() sooner shortlog: run setup_git_directory_gently() sooner git wrapper: allow setup_git_directory_gently() be called earlier setup: remember whether repository was found git wrapper: introduce startup_info struct Conflicts: builtin/index-pack.c
2010-08-15config: run setup_git_directory_gently() soonerLibravatar Nguyễn Thái Ngọc Duy1-3/+2
For the pager choice (and the choice to paginate) to reflect the current repository configuration, the repository needs to be located first. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-04config: add --local optionLibravatar Sverre Rabbelier1-2/+5
This is a shorthand similar to --system but instead uses the config file of the current repository. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28Allow passing of configuration parameters in the command lineLibravatar Alex Riesen1-1/+5
The values passed this way will override whatever is defined in the config files. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Move 'builtin-*' into a 'builtin/' subdirectoryLibravatar Linus Torvalds1-0/+496
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>