aboutsummaryrefslogtreecommitdiff
path: root/builtin/config.c
Commit message (Collapse)AuthorAge
* Merge branch 'jk/config-ignore-duplicates'Junio C Hamano2012-11-21
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * builtin/config.c: Fix a sparse warningRamsay Jones2012-10-29
| | | | | | | | | | | | | | | | | | | | | | 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 <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jeff King <peff@peff.net>
| * git-config: use git_config_with_optionsJeff King2012-10-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net>
| * git-config: do not complain about duplicate entriesJeff King2012-10-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 user.email one@example.com $ git config --add user.email two@example.com [use the internal parser to fetch it] $ git var GIT_AUTHOR_IDENT Your Name <two@example.com> ... [use git-config to fetch it] $ git config user.email one@example.com error: More than one value for the key user.email: two@example.com 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 <peff@peff.net>
| * git-config: collect values instead of immediately printingJeff King2012-10-24
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net>
| * git-config: fix regexp memory leaks on error conditionsJeff King2012-10-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net>
| * git-config: remove memory leak of key regexpJeff King2012-10-24
| | | | | | | | | | | | | | 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 <peff@peff.net>
* | Merge branch 'cn/config-missing-path'Junio C Hamano2012-11-20
|\ \ | |/ |/| | | | | | | | | | | "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
| * config: don't segfault when given --path with a missing valueCarlos Martín Nieto2012-11-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <cmn@elego.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'nd/i18n-parseopt-help'Junio C Hamano2012-09-07
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * | Use imperative form in help usage to describe an actionNguyễn Thái Ngọc Duy2012-08-22
| | | | | | | | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | i18n: config: mark parseopt strings for translationNguyễn Thái Ngọc Duy2012-08-20
| |/ | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/config-warn-on-inaccessible-paths'Junio C Hamano2012-09-07
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | config: warn on inaccessible filesJeff King2012-08-21
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jc/maint-config-exit-status'Junio C Hamano2012-09-03
|\ \ | |/ |/| | | | | | | | | | | | | | | 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
| * config: "git config baa" should exit with status 1Junio C Hamano2012-07-30
| | | | | | | | | | | | | | 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>
* | config: fix several access(NULL) callsMatthieu Moy2012-07-16
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | config: write to $XDG_CONFIG_HOME/git/config file when appropriateHuynh Khoi Nguyen Nguyen2012-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | config: read (but not write) from $XDG_CONFIG_HOME/git/config fileHuynh Khoi Nguyen Nguyen2012-06-25
|/ | | | | | | | | | | | | | | | | | | | | | | | | 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>
* config: remove useless assignmentRené Scharfe2012-03-28
| | | | | | | | | | | 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>
* config: add include directiveJeff King2012-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* config: stop using config_exclusive_filenameJeff King2012-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* config: copy the return value of prefix_filenameJeff King2012-02-17
| | | | | | | | | | | | | | 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>
* Merge branch 'jv/maint-config-set' into maintJunio C Hamano2011-12-28
|\ | | | | | | | | * jv/maint-config-set: Fix an incorrect reference to --set-all.
| * Fix an incorrect reference to --set-all.Jelmer Vernooij2011-12-27
| | | | | | | | | | Signed-off-by: Jelmer Vernooij <jelmer@samba.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'mm/maint-config-explicit-bool-display'Junio C Hamano2011-10-17
|\ \ | | | | | | | | | | | | * mm/maint-config-explicit-bool-display: config: display key_delim for config --bool --get-regexp
| * | config: display key_delim for config --bool --get-regexpMatthieu Moy2011-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | config: refactor get_colorbool functionJeff King2011-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | color: delay auto-color decision until point of useJeff King2011-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | git_config_colorbool: refactor stdout_is_tty handlingJeff King2011-08-18
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | config: Give error message when not changing a multivarMichael J Gruber2011-05-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | config: drop support for GIT_CONFIG_NOGLOBALJonathan Nieder2011-03-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'lp/config-vername-check'Junio C Hamano2011-02-27
|\ \ | | | | | | | | | | | | | | | * lp/config-vername-check: Disallow empty section and variable names Sanity-check config variable names
| * | Sanity-check config variable namesLibor Pechacek2011-02-22
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'mg/placeholders-are-lowercase'Junio C Hamano2011-02-27
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | Make <identifier> lowercase as per CodingGuidelinesMichael J Gruber2011-02-15
| |/ | | | | | | | | | | | | *.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>
* | repo-config: add deprecation warningRené Scharfe2011-02-13
|/ | | | | | | | | 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>
* Merge branch 'jn/paginate-fix'Junio C Hamano2010-08-31
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * config: run setup_git_directory_gently() soonerNguyễn Thái Ngọc Duy2010-08-15
| | | | | | | | | | | | | | | | | | | | | | 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>
* | config: add --local optionSverre Rabbelier2010-08-04
|/ | | | | | | | 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>
* Allow passing of configuration parameters in the command lineAlex Riesen2010-03-28
| | | | | | | | 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>
* Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds2010-02-22
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>