summaryrefslogtreecommitdiff
path: root/t/t1300-repo-config.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-02-27Merge branch 'jk/sq-dequote-on-bogus-input'Libravatar Junio C Hamano1-0/+23
Code to unquote single-quoted string (used in the parser for configuration files, etc.) did not diagnose bogus input correctly and produced bogus results instead. * jk/sq-dequote-on-bogus-input: sq_dequote: fix extra consumption of source string
2018-02-14sq_dequote: fix extra consumption of source stringLibravatar Jeff King1-0/+23
This fixes a (probably harmless) parsing problem in sq_dequote_step(), in which we parse some bogus input incorrectly rather than complaining that it's bogus. Our shell-dequoting function is very strict: it can unquote everything generated by sq_quote(), but not arbitrary strings. In particular, it only allows characters outside of the single-quoted string if they are immediately backslashed and then the single-quoted string is resumed. So: 'foo'\''bar' is OK. But these are not: 'foo'\'bar 'foo'\' 'foo'\'\''bar' even though they are all valid shell. The parser has a funny corner case here. When we see a backslashed character, we keep incrementing the "src" pointer as we parse it. For a single sq_dequote() call, that's OK; our next step is to bail with an error, and we don't care where "src" points. But if we're parsing multiple strings with sq_dequote_to_argv(), then our next step is to see if the string is followed by whitespace. Because we erroneously incremented the "src" pointer, we don't barf on the bogus backslash that we skipped. Instead, we may find whitespace that immediately follows it, and continue as if all is well (skipping the backslashed character completely!). In practice, this shouldn't be a big deal. The input is bogus, and our sq_quote() would never generate this bogus input. In all but one callers, we are parsing input created by an earlier call to sq_quote(). That final case is "git shell", which parses shell-quoting generated by the client. And in that case we use the singular sq_quote(), which has always behaved correctly. One might also wonder if you could provoke a read past the end of the string. But the answer is no; we still parse character by character, and would never advance past a NUL. This patch implements the minimal fix, along with documenting the restriction (which confused at least me while reading the code). We should possibly consider being more liberal in accepting valid shell-quoted words. I suspect the code may actually be simpler, and it would be more friendly to anybody generating or editing input by hand. But I wanted to fix just the immediate bug in this patch. We don't have a direct way to unit-test the sq_dequote() functions, but we can do this by feeding input to GIT_CONFIG_PARAMETERS (which is not normally a user-facing interface, but serves here as it expects to see sq_quote() input from "git -c"). I've included both a bogus example, and a related "good" one to confirm that we still parse it correctly. Noticed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-18config: add --expiry-dateLibravatar Haaris Mehmood1-0/+30
Add --expiry-date as a data-type for config files when 'git config --get' is used. This will return any relative or fixed dates from config files as timestamps. This is useful for scripts (e.g. gc.reflogexpire) that work with timestamps so that '2.weeks' can be converted to a format acceptable by those scripts/functions. Following the convention of git_config_pathname(), move the helper function required for this feature from builtin/reflog.c to builtin/config.c where other similar functions exist (e.g. for --bool or --path), and match the order of parameters with other functions (i.e. output pointer as first parameter). Signed-off-by: Haaris Mehmood <hsed@unimetic.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-20Merge branch 'js/alias-case-sensitivity'Libravatar Junio C Hamano1-0/+7
A recent update broke an alias that contained an uppercase letter. * js/alias-case-sensitivity: alias: compare alias name *case-insensitively* t1300: demonstrate that CamelCased aliases regressed
2017-07-17alias: compare alias name *case-insensitively*Libravatar Johannes Schindelin1-1/+1
It is totally legitimate to add CamelCased aliases, but due to the way config keys are compared, the case does not matter. Therefore, we must compare the alias name insensitively to the config keys. This fixes a regression introduced by a9bcf6586d1 (alias: use the early config machinery to expand aliases, 2017-06-14). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17t1300: demonstrate that CamelCased aliases regressedLibravatar Johannes Schindelin1-0/+7
It is totally legitimate to add CamelCased aliases, but due to the way config keys are compared, the case does not matter. Except that now it does: the alias name is expected to be all lower-case. This is a regression introduced by a9bcf6586d1 (alias: use the early config machinery to expand aliases, 2017-06-14). Noticed by Alejandro Pauly, diagnosed by Kevin Willford. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-24Merge branch 'js/alias-early-config'Libravatar Junio C Hamano1-0/+6
The code to pick up and execute command alias definition from the configuration used to switch to the top of the working tree and then come back when the expanded alias was executed, which was unnecessarilyl complex. Attempt to simplify the logic by using the early-config mechanism that does not chdir around. * js/alias-early-config: alias: use the early config machinery to expand aliases t7006: demonstrate a problem with aliases in subdirectories t1308: relax the test verifying that empty alias values are disallowed help: use early config when autocorrecting aliases config: report correct line number upon error discover_git_directory(): avoid setting invalid git_dir
2017-06-15config: report correct line number upon errorLibravatar Johannes Schindelin1-0/+6
When get_value() parses a key/value pair, it is possible that the line number is decreased (because the \n has been consumed already) before the key/value pair is passed to the callback function, to allow for the correct line to be attributed in case of an error. However, when git_parse_source() asks get_value() to parse the key/value pair, the error reporting is performed *after* get_value() returns. Which means that we have to be careful not to increase the line number in get_value() after the callback function returned an error. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-15config: complain about --local outside of a git repoLibravatar Jeff King1-1/+1
The "--local" option instructs git-config to read or modify the repository-level config. This doesn't make any sense if you're not actually in a repository. Older versions of Git would blindly try to read or write ".git/config". For reading, this would result in a quiet failure, since there was no config to read (and thus no matching config value). Writing would generally fail noisily, since ".git" was unlikely to exist. But since b1ef400ee (setup_git_env: avoid blind fall-back to ".git", 2016-10-20), we catch this in the call to git_pathdup() and die with an assertion. Dying is the right thing to do, but we should catch the problem early and give a more human-friendly error message. Note that even without --local, git-config will sometimes default to using local repository config (e.g., when writing). These cases are already protected by similar checks, and covered by a test in t1308. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-15setup_git_env: convert die("BUG") to BUG()Libravatar Jeff King1-0/+6
Converting to BUG() makes it easier to detect and debug cases where we hit this assertion. Coupled with a new test in t1300, this shows that the test suite can detect such corner cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-10Merge branch 'jc/config-case-cmdline-take-2'Libravatar Junio C Hamano1-0/+62
The code to parse "git -c VAR=VAL cmd" and set configuration variable for the duration of cmd had two small bugs, which have been fixed. * jc/config-case-cmdline-take-2: config: use git_config_parse_key() in git_config_parse_parameter() config: move a few helper functions up
2017-02-23config: use git_config_parse_key() in git_config_parse_parameter()Libravatar Junio C Hamano1-0/+62
The parsing of one-shot assignments of configuration variables that come from the command line historically was quite loose and allowed anything to pass. It also downcased everything in the variable name, even a three-level <section>.<subsection>.<variable> name in which the <subsection> part must be treated in a case sensitive manner. Existing git_config_parse_key() helper is used to parse the variable name that comes from the command line, i.e. "git config VAR VAL", and handles these details correctly. Replace the strbuf_tolower() call in git_config_parse_parameter() with a call to it to correct both issues. git_config_parse_key() does a bit more things that are not necessary for the purpose of this codepath (e.g. it allocates a separate buffer to return the canonicalized variable name because it takes a "const char *" input), but we are not in a performance-critical codepath here. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-01urlmatch: allow globbing for the URL host partLibravatar Patrick Steinhardt1-0/+72
The URL matching function computes for two URLs whether they match not. The match is performed by splitting up the URL into different parts and then doing an exact comparison with the to-be-matched URL. The main user of `urlmatch` is the configuration subsystem. It allows to set certain configurations based on the URL which is being connected to via keys like `http.<url>.*`. A common use case for this is to set proxies for only some remotes which match the given URL. Unfortunately, having exact matches for all parts of the URL can become quite tedious in some setups. Imagine for example a corporate network where there are dozens or even hundreds of subdomains, which would have to be configured individually. Allow users to write an asterisk '*' in place of any 'host' or 'subdomain' label as part of the host name. For example, "http.https://*.example.com.proxy" sets "http.proxy" for all direct subdomains of "https://example.com", e.g. "https://foo.example.com", but not "https://foo.bar.example.com". Signed-off-by: Patrick Steinhardt <patrick.steinhardt@elego.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-01urlmatch: include host in urlmatch rankingLibravatar Patrick Steinhardt1-0/+33
In order to be able to rank positive matches by `urlmatch`, we inspect the path length and user part to decide whether a match is better than another match. As all other parts are matched exactly between both URLs, this is the correct thing to do right now. In the future, though, we want to introduce wild cards for the domain part. When doing this, it does not make sense anymore to only compare the path lengths. Instead, we also want to compare the domain lengths to determine which of both URLs matches the host part more closely. Signed-off-by: Patrick Steinhardt <patrick.steinhardt@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17tests: use test_i18n* functions to suppress false positivesLibravatar Vasco Almeida1-4/+4
The test functions test_i18ncmp and test_i18ngrep pretend success if run under GETTEXT_POISON. By using those functions to test output which is correctly marked as translatable, enables one to detect if the strings newly marked for translation are from plumbing output. If they are indeed from plumbing, the test would fail, and the string should be unmarked, since it is not seen by users. Thus, it is productive to not have false positives when running the test under GETTEXT_POISON. This commit replaces normal test functions by their i18n aware variants in use-cases know to be correctly marked for translation, suppressing false positives. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06Merge branch 'jk/submodule-c-credential'Libravatar Junio C Hamano1-0/+14
"git -c credential.<var>=<value> submodule" can now be used to propagate configuration variables related to credential helper down to the submodules. * jk/submodule-c-credential: git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS git: submodule honor -c credential.* from command line quote: implement sq_quotef() submodule: fix segmentation fault in submodule--helper clone submodule: fix submodule--helper clone usage submodule: check argc count for git submodule--helper clone submodule: don't pass empty string arguments to submodule--helper clone
2016-04-03Merge branch 'jk/config-get-urlmatch'Libravatar Junio C Hamano1-0/+3
"git config --get-urlmatch", unlike other variants of the "git config --get" family, did not signal error with its exit status when there was no matching configuration. * jk/config-get-urlmatch: Documentation/git-config: fix --get-all description Documentation/git-config: use bulleted list for exit codes config: fail if --get-urlmatch finds no value
2016-03-23git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERSLibravatar Jeff King1-0/+14
The "git -c var=value" option stuffs the config value into $GIT_CONFIG_PARAMETERS, so that sub-processes can see it. When the config is later read via git_config() or similar, we parse it back out of that variable. The parsing end is a little bit picky; it assumes that each entry was generated with sq_quote_buf(), and that there is no extraneous whitespace. On the generating end, we are careful to append to an existing $GIT_CONFIG_PARAMETERS variable if it exists. However, our test for "should we add a space separator" is too liberal: it will add one even if the environment variable exists but is empty. As a result, you might end up with: GIT_CONFIG_PARAMETERS=" 'core.foo=bar'" which the parser will choke on. This was hard to trigger in older versions of git, since we only set the variable when we had something to put into it (though you could certainly trigger it manually). But since 14111fc (git: submodule honor -c credential.* from command line, 2016-02-29), the submodule code will unconditionally put the $GIT_CONFIG_PARAMETERS variable into the environment of any operation in the submodule, whether it is empty or not. So any of those operations which themselves use "git -c" will generate the unparseable value and fail. We can easily fix it by catching this case on the generating side. While we're adding a test, let's also check that multiple layers of "git -c" work, which was previously not tested at all. Reported-by: Shin Fan <shinfan@google.com> Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Tested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-23t1300: fix the new --show-origin tests on WindowsLibravatar Johannes Schindelin1-3/+6
On Windows, we have that funny situation where the test script can refer to POSIX paths because it runs in a shell that uses a POSIX emulation layer ("MSYS2 runtime"). Yet, git.exe does *not* understand POSIX paths at all but only pure Windows paths. So let's just convert the POSIX paths to Windows paths before passing them on to Git, using `pwd` (which is already modified on Windows to output Windows paths). While fixing the new tests on Windows, we also have to exclude the tests that want to write a file with a name that is illegal on Windows (unfortunately, there is more than one test trying to make use of that file). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-23t1300-repo-config: make it resilient to being run via 'sh -x'Libravatar Johannes Schindelin1-6/+2
One way to diagnose broken regression tests is to run the test script using 'sh -x t... -i -v' to find out which call actually demonstrates the symptom. Hence it is pretty counterproductive if the test script behaves differently when being run via 'sh -x', in particular when using test_cmp or test_i18ncmp on redirected stderr. A more recent way "sh tXXXX -i -v -x" has the same issue. So let's use test_i18ngrep (as suggested by Jonathan Nieder) instead of test_cmp/test_i18ncmp to verify that stderr looks as expected. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-28config: fail if --get-urlmatch finds no valueLibravatar John Keeping1-0/+3
The --get, --get-all and --get-regexp options to git-config exit with status 1 if the key is not found but --get-urlmatch succeeds in this case. Change --get-urlmatch to behave in the same way as the other --get* options so that all four are consistent. --get-color is a special case because it accepts a default value to return and so should not return an error if the key is not found. Also clarify this behaviour in the documentation. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22config: add '--show-origin' option to print the origin of a config valueLibravatar Lars Schneider1-0/+147
If config values are queried using 'git config' (e.g. via --get, --get-all, --get-regexp, or --list flag) then it is sometimes hard to find the configuration file where the values were defined. Teach 'git config' the '--show-origin' option to print the source configuration file for every printed value. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22config: add 'origin_type' to config_source structLibravatar Lars Schneider1-1/+7
Use the config origin_type to print more detailed error messages that inform the user about the origin of a config error (file, stdin, blob). Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17t: do not hide Git's exit code in tests using 'nul_to_q'Libravatar Lars Schneider1-2/+4
Git should not be on the left-hand side of a pipe, because it hides the exit code, and we want to make sure git does not fail. Fix all invocations of 'nul_to_q' (defined in /t/test-lib-functions.sh) using this pattern. There is one more occurrence of the pattern in t9010-svn-fe.sh which is too evolved to change it easily. All remaining test code that does not adhere to the pattern can be found with the following command: git grep -E 'git.*[^|]\|($|[^|])' Helped-by: Jeff King <peff@peff.net> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10config: add '--name-only' option to list only variable namesLibravatar SZEDER Gábor1-0/+22
'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 <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix moderate &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, but in a way that probably does not effect the outcome of the test. Most of these are of the form: some_cmd >actual test_cmp expect actual The main point of the test is to verify the output, and a failure in some_cmd would probably be noticed by bogus output. But it is good for the tests to also confirm that "some_cmd" does not die unexpectedly after producing its output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix severe &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, in a location which causes a significant portion of the test to be missed (e.g., the test effectively does nothing, or consists of a long string of actions and output comparisons, and we throw away the exit code of at least one part of the string). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-09Merge branch 'jk/command-line-config-empty-string'Libravatar Junio C Hamano1-0/+11
"git -c section.var command" and "git -c section.var= command" should pass the configuration differently (the former should be a boolean true, the latter should be an empty string). * jk/command-line-config-empty-string: config: teach "git -c" to recognize an empty string
2014-08-05config: teach "git -c" to recognize an empty stringLibravatar Junio C Hamano1-0/+11
In a config file, you can do: [foo] bar to turn the "foo.bar" boolean flag on, and you can do: [foo] bar= to set "foo.bar" to the empty string. However, git's "-c" parameter treats both: git -c foo.bar and git -c foo.bar= as the boolean flag, and there is no way to set a variable to the empty string. This patch enables the latter form to do that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21test prerequisites: eradicate NOT_FOOLibravatar Junio C Hamano1-3/+3
Support for Back when bdccd3c1 (test-lib: allow negation of prerequisites, 2012-11-14) introduced negated predicates (e.g. "!MINGW,!CYGWIN"), we already had 5 test files that use NOT_MINGW (and a few MINGW) as prerequisites. Let's not add NOT_FOO and rewrite existing ones as !FOO for both MINGW and CYGWIN. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-03Merge branch 'ew/config-protect-mode'Libravatar Junio C Hamano1-0/+10
* ew/config-protect-mode: config: preserve config file permissions on edits
2014-05-06config: preserve config file permissions on editsLibravatar Eric Wong1-0/+10
Users may already store sensitive data such as imap.pass in .git/config; making the file world-readable when "git config" is called to edit means their password would be compromised on a shared system. [v2: updated for section renames, as noted by Junio] Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31Merge branch 'jk/tests-cleanup'Libravatar Junio C Hamano1-14/+14
* jk/tests-cleanup: t0001: drop subshells just for "cd" t0001: drop useless subshells t0001: use test_must_fail t0001: use test_config_global t0001: use test_path_is_* t0001: make symlink reinit test more careful t: prefer "git config --file" to GIT_CONFIG t: prefer "git config --file" to GIT_CONFIG with test_must_fail t: stop using GIT_CONFIG to cross repo boundaries t: drop useless sane_unset GIT_* calls t/test-lib: drop redundant unset of GIT_CONFIG t/Makefile: stop setting GIT_CONFIG
2014-03-31Merge branch 'dt/tests-with-env-not-subshell'Libravatar Junio C Hamano1-13/+4
* dt/tests-with-env-not-subshell: tests: use "env" to run commands with temporary env-var settings
2014-03-21t: prefer "git config --file" to GIT_CONFIGLibravatar Jeff King1-10/+10
Doing: GIT_CONFIG=foo git config ... is equivalent to: git config --file=foo ... The latter is easier to read and slightly less error-prone, because of issues with one-shot variables and shell functions (e.g., you cannot use the former with test_must_fail). Note that we explicitly leave one case in t1300 which checks the same operation on both GIT_CONFIG and "git config --file". They are equivalent in the code these days, but this will make sure it remains so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21t: prefer "git config --file" to GIT_CONFIG with test_must_failLibravatar Jeff King1-4/+4
This lets us get rid of an extra "env" invocation in the middle, and is slightly more readable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-19tests: use "env" to run commands with temporary env-var settingsLibravatar David Tran1-13/+4
Ordinarily, we would say "VAR=VAL command" to execute a tested command with environment variable(s) set only for that command. This however does not work if 'command' is a shell function (most notably 'test_must_fail'); the result of the assignment is retained and affects later commands. To avoid this, we used to assign and export environment variables and run such a test in a subshell, like so: ( VAR=VAL && export VAR && test_must_fail git command to be tested ) But with "env" utility, we should be able to say: test_must_fail env VAR=VAL git command to be tested which is much shorter and easier to read. Signed-off-by: David Tran <unsignedzero@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-18config: teach "git config --file -" to read from the standard inputLibravatar Kirill A. Shutemov1-2/+15
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 <kirill@shutemov.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-12Merge branch 'jk/config-int-range-check'Libravatar Junio C Hamano1-3/+10
"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-09git-config: always treat --int as 64-bit internallyLibravatar Jeff King1-0/+7
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09config: make numeric parsing errors more clearLibravatar Jeff King1-3/+3
If we try to parse an integer config argument and get a number outside of the representable range, we die with the cryptic message: "bad config value for '%s'". We can improve two things: 1. Show the value that produced the error (e.g., bad config value '3g' for 'foo.bar'). 2. Mention the reason the value was rejected (e.g., "invalid unit" versus "out of range"). A few tests need to be updated with the new output, but that should not be representative of real-world breakage, as scripts should not be depending on the exact text of our stderr output, which is subject to i18n anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05config: "git config --get-urlmatch" parses section.<url>.keyLibravatar Junio C Hamano1-0/+25
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 "https://weak.example.com"] cookieFile = /tmp/cookie.txt sslVerify = false You would get $ git config --bool --get-urlmatch http.sslVerify https://good.example.com true $ git config --bool --get-urlmatch http.sslVerify https://weak.example.com 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 https://weak.example.com http.cookiefile /tmp/cookie.txt http.sslverify false Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-29t1300: document some aesthetic failures of the config editorLibravatar Jeff King1-0/+35
The config-editing code used by "git config var value" is built around the regular config callback parser, whose only triggerable item is an actual key. As a result, it does not know anything about section headers, which can result in unnecessarily ugly output: 1. When we delete the last key in a section, we should be able to delete the section header. 2. When we add a key into a section, we should be able to reuse the same section header, even if that section did not have any keys in it already. Unfortunately, fixing these is not trivial with the current code. It would involve the config parser recording and passing back information on each item it finds, including headers, keys, and even comments (or even better, generating an actual in-memory parse-tree). Since these behaviors do not cause any functional problems (i.e., the resulting config parses as expected, it is just uglier than one would like), fixing them can wait until somebody feels like substantially refactoring the parsing code. In the meantime, let's document them as known issues with some tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-21Merge branch 'jk/config-ignore-duplicates'Libravatar Junio C Hamano1-129/+187
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'Libravatar Junio C Hamano1-0/+5
"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-15config: don't segfault when given --path with a missing valueLibravatar Carlos Martín Nieto1-0/+5
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>
2012-10-24git-config: do not complain about duplicate entriesLibravatar Jeff King1-2/+4
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>
2012-10-24t1300: test "git config --get-all" more thoroughlyLibravatar Jeff King1-2/+7
We check that we can "--get-all" a multi-valued variable, but we do not actually confirm that the output is sensible. Doing so reveals that it works fine, but this will help us ensure we do not have regressions in the next few patches, which will touch this area. Signed-off-by: Jeff King <peff@peff.net>
2012-10-24t1300: remove redundant testLibravatar Jeff King1-4/+0
This test checks that git-config fails for an ambiguous "get", but we check the exact same thing 3 tests beforehand. Signed-off-by: Jeff King <peff@peff.net>
2012-10-24t1300: style updatesLibravatar Jeff King1-123/+178
The t1300 test script is quite old, and does not use our modern techniques or styles. This patch updates it in the following ways: 1. Use test_cmp instead of cmp (to make failures easier to debug). 2. Use test_cmp instead of 'test $(command) = expected'. This makes failures much easier to debug, and also makes sure that $(command) exits appropriately. 3. Use test_must_fail (easier to read, and checks more rigorously for signal death). 4. Write tests with the usual style of: test_expect_success 'test name' ' test commands && ... ' rather than one-liners, or using backslash-continuation. This is purely a style fixup. There are still a few command happening outside of test_expect invocations, but they are all innoccuous system commands like "cat" and "cp". In an ideal world, each test would be self sufficient and all commands would happen inside test_expect, but it is not immediately obvious how the grouping should work (some of the commands impact the subsequent tests, and some of them are setting up and modifying state that many tests depend on). This patch just picks the low-hanging style fruit, and we can do more fixes on top later. Signed-off-by: Jeff King <peff@peff.net>