summaryrefslogtreecommitdiff
path: root/t/t1300-config.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-05-07Merge branch 'ps/config-global-override'Libravatar Junio C Hamano1-0/+85
Replace GIT_CONFIG_NOSYSTEM mechanism to decline from reading the system-wide configuration file with GIT_CONFIG_SYSTEM that lets users specify from which file to read the system-wide configuration (setting it to an empty file would essentially be the same as setting NOSYSTEM), and introduce GIT_CONFIG_GLOBAL to override the per-user configuration in $HOME/.gitconfig. * ps/config-global-override: t1300: fix unset of GIT_CONFIG_NOSYSTEM leaking into subsequent tests config: allow overriding of global and system configuration config: unify code paths to get global config paths config: rename `git_etc_config()`
2021-05-07Merge branch 'ps/config-env-option-with-separate-value'Libravatar Junio C Hamano1-1/+14
"git --config-env var=val cmd" weren't accepted (only --config-env=var=val was). * ps/config-env-option-with-separate-value: git: support separate arg for `--config-env`'s value git.txt: fix synopsis of `--config-env` missing the equals sign
2021-04-30git: support separate arg for `--config-env`'s valueLibravatar Patrick Steinhardt1-1/+14
While not documented as such, many of the top-level options like `--git-dir` and `--work-tree` support two syntaxes: they accept both an equals sign between option and its value, and they do support option and value as two separate arguments. The recently added `--config-env` option only supports the syntax with an equals sign. Mitigate this inconsistency by accepting both syntaxes and add tests to verify both work. Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-27t1300: fix unset of GIT_CONFIG_NOSYSTEM leaking into subsequent testsLibravatar Patrick Steinhardt1-4/+3
In order to test whether the new GIT_CONFIG_SYSTEM environment variable behaves as expected, we unset GIT_CONFIG_NOSYSTEM in one of our tests in t1300. But because tests are not executed in a subshell, this unset leaks into all subsequent tests and may thus cause them to fail in some environments. These failures are easily reproducable with `make prefix=/root test`. Fix the issue by not using `sane_unset GIT_CONFIG_NOSYSTEM`, but instead just manually add it to the environment of the two command invocations which need it. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-19config: allow overriding of global and system configurationLibravatar Patrick Steinhardt1-0/+86
In order to have git run in a fully controlled environment without any misconfiguration, it may be desirable for users or scripts to override global- and system-level configuration files. We already have a way of doing this, which is to unset both HOME and XDG_CONFIG_HOME environment variables and to set `GIT_CONFIG_NOGLOBAL=true`. This is quite kludgy, and unsetting the first two variables likely has an impact on other executables spawned by such a script. The obvious way to fix this would be to introduce `GIT_CONFIG_NOGLOBAL` as an equivalent to `GIT_CONFIG_NOSYSTEM`. But in the past, it has turned out that this design is inflexible: we cannot test system-level parsing of the git configuration in our test harness because there is no way to change its location, so all tests run with `GIT_CONFIG_NOSYSTEM` set. Instead of doing the same mistake with `GIT_CONFIG_NOGLOBAL`, introduce two new variables `GIT_CONFIG_GLOBAL` and `GIT_CONFIG_SYSTEM`: - If unset, git continues to use the usual locations. - If set to a specific path, we skip reading the normal configuration files and instead take the path. By setting the path to `/dev/null`, no configuration will be loaded for the respective level. This implements the usecase where we want to execute code in a sanitized environment without any potential misconfigurations via `/dev/null`, but is more flexible and allows for more usecases than simply adding `GIT_CONFIG_NOGLOBAL`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-17Merge branch 'ak/config-bad-bool-error'Libravatar Junio C Hamano1-0/+7
The error message given when a configuration variable that is expected to have a boolean value has been improved. * ak/config-bad-bool-error: config: improve error message for boolean config
2021-02-11config: improve error message for boolean configLibravatar Andrew Klotz1-0/+7
Currently invalid boolean config values return messages about 'bad numeric', which is slightly misleading when the error was due to a boolean value. We can improve the developer experience by returning a boolean error message when we know the value is neither a bool text or int. before with an invalid boolean value of `non-boolean`, its unclear what numeric is referring to: fatal: bad numeric config value 'non-boolean' for 'commit.gpgsign': invalid unit now the error message mentions `non-boolean` is a bad boolean value: fatal: bad boolean config value 'non-boolean' for 'commit.gpgsign' Signed-off-by: Andrew Klotz <agc.klotz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-25Merge branch 'ps/config-env-pairs'Libravatar Junio C Hamano1-1/+222
Introduce two new ways to feed configuration variable-value pairs via environment variables, and tweak the way GIT_CONFIG_PARAMETERS encodes variable/value pairs to make it more robust. * ps/config-env-pairs: config: allow specifying config entries via envvar pairs environment: make `getenv_safe()` a public function config: store "git -c" variables using more robust format config: parse more robust format in GIT_CONFIG_PARAMETERS config: extract function to parse config pairs quote: make sq_dequote_step() a public function config: add new way to pass config via `--config-env` git: add `--super-prefix` to usage string
2021-01-25Merge branch 'js/default-branch-name-tests-final-stretch'Libravatar Junio C Hamano1-4/+7
Prepare tests not to be affected by the name of the default branch "git init" creates. * js/default-branch-name-tests-final-stretch: (28 commits) tests: drop prereq `PREPARE_FOR_MAIN_BRANCH` where no longer needed t99*: adjust the references to the default branch name "main" tests(git-p4): transition to the default branch name `main` t9[5-7]*: adjust the references to the default branch name "main" t9[0-4]*: adjust the references to the default branch name "main" t8*: adjust the references to the default branch name "main" t7[5-9]*: adjust the references to the default branch name "main" t7[0-4]*: adjust the references to the default branch name "main" t6[4-9]*: adjust the references to the default branch name "main" t64*: preemptively adjust alignment to prepare for `master` -> `main` t6[0-3]*: adjust the references to the default branch name "main" t5[6-9]*: adjust the references to the default branch name "main" t55[4-9]*: adjust the references to the default branch name "main" t55[23]*: adjust the references to the default branch name "main" t551*: adjust the references to the default branch name "main" t550*: adjust the references to the default branch name "main" t5503: prepare aligned comment for replacing `master` with `main` t5[0-4]*: adjust the references to the default branch name "main" t5323: prepare centered comment for `master` -> `main` t4*: adjust the references to the default branch name "main" ...
2021-01-15config: allow specifying config entries via envvar pairsLibravatar Patrick Steinhardt1-1/+114
While we currently have the `GIT_CONFIG_PARAMETERS` environment variable which can be used to pass runtime configuration data to git processes, it's an internal implementation detail and not supposed to be used by end users. Next to being for internal use only, this way of passing config entries has a major downside: the config keys need to be parsed as they contain both key and value in a single variable. As such, it is left to the user to escape any potentially harmful characters in the value, which is quite hard to do if values are controlled by a third party. This commit thus adds a new way of adding config entries via the environment which gets rid of this shortcoming. If the user passes the `GIT_CONFIG_COUNT=$n` environment variable, Git will parse environment variable pairs `GIT_CONFIG_KEY_$i` and `GIT_CONFIG_VALUE_$i` for each `i` in `[0,n)`. While the same can be achieved with `git -c <name>=<value>`, one may wish to not do so for potentially sensitive information. E.g. if one wants to set `http.extraHeader` to contain an authentication token, doing so via `-c` would trivially leak those credentials via e.g. ps(1), which typically also shows command arguments. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-15config: store "git -c" variables using more robust formatLibravatar Patrick Steinhardt1-0/+8
The previous commit added a new format for $GIT_CONFIG_PARAMETERS which is able to robustly handle subsections with "=" in them. Let's start writing the new format. Unfortunately, this does much less than you'd hope, because "git -c" itself has the same ambiguity problem! But it's still worth doing: - we've now pushed the problem from the inter-process communication into the "-c" command-line parser. This would free us up to later add an unambiguous format there (e.g., separate arguments like "git --config key value", etc). - for --config-env, the parser already disallows "=" in the environment variable name. So: git --config-env section.with=equals.key=ENVVAR will robustly set section.with=equals.key to the contents of $ENVVAR. The new test shows the improvement for --config-env. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-15config: parse more robust format in GIT_CONFIG_PARAMETERSLibravatar Jeff King1-0/+52
When we stuff config options into GIT_CONFIG_PARAMETERS, we shell-quote each one as a single unit, like: 'section.one=value1' 'section.two=value2' On the reading side, we de-quote to get the individual strings, and then parse them by splitting on the first "=" we find. This format is ambiguous, because an "=" may appear in a subsection. So the config represented in a file by both: [section "subsection=with=equals"] key = value and: [section] subsection = with=equals.key=value ends up in this flattened format like: 'section.subsection=with=equals.key=value' and we can't tell which was desired. We have traditionally resolved this by taking the first "=" we see starting from the left, meaning that we allowed arbitrary content in the value, but not in the subsection. Let's make our environment format a bit more robust by separately quoting the key and value. That turns those examples into: 'section.subsection=with=equals.key'='value' and: 'section.subsection'='with=equals.key=value' respectively, and we can tell the difference between them. We can detect which format is in use for any given element of the list based on the presence of the unquoted "=". That means we can continue to allow the old format to work to support any callers which manually used the old format, and we can even intermingle the two formats. The old format wasn't documented, and nobody was supposed to be using it. But it's likely that such callers exist in the wild, so it's nice if we can avoid breaking them. Likewise, it may be possible to trigger an older version of "git -c" that runs a script that calls into a newer version of "git -c"; that new version would see the intermingled format. This does create one complication, which is that the obvious format in the new scheme for [section] some-bool is: 'section.some-bool' with no equals. We'd mistake that for an old-style variable. And it even has the same meaning in the old style, but: [section "with=equals"] some-bool does not. It would be: 'section.with=equals=some-bool' which we'd take to mean: [section] with = equals=some-bool in the old, ambiguous style. Likewise, we can't use: 'section.some-bool'='' because that's ambiguous with an actual empty string. Instead, we'll again use the shell-quoting to give us a hint, and use: 'section.some-bool'= to show that we have no value. Note that this commit just expands the reading side. We'll start writing the new format via "git -c" in a future patch. In the meantime, the existing "git -c" tests will make sure we didn't break reading the old format. But we'll also add some explicit coverage of the two formats to make sure we continue to handle the old one after we move the writing side over. And one final note: since we're now using the shell-quoting as a semantically meaningful hint, this closes the door to us ever allowing arbitrary shell quoting, like: 'a'shell'would'be'ok'with'this'.key=value But we have never supported that (only what sq_quote() would produce), and we are probably better off keeping things simple, robust, and backwards-compatible, than trying to make it easier for humans. We'll continue not to advertise the format of the variable to users, and instead keep "git -c" as the recommended mechanism for setting config (even if we are trying to be kind not to break users who may be relying on the current undocumented format). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-12config: add new way to pass config via `--config-env`Libravatar Patrick Steinhardt1-0/+48
While it's already possible to pass runtime configuration via `git -c <key>=<value>`, it may be undesirable to use when the value contains sensitive information. E.g. if one wants to set `http.extraHeader` to contain an authentication token, doing so via `-c` would trivially leak those credentials via e.g. ps(1), which typically also shows command arguments. To enable this usecase without leaking credentials, this commit introduces a new switch `--config-env=<key>=<envvar>`. Instead of directly passing a value for the given key, it instead allows the user to specify the name of an environment variable. The value of that variable will then be used as value of the key. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04t1300: don't needlessly work with `core.foo` configsLibravatar Martin Ågren1-30/+30
We use various made-up config keys in the "core" section for no real reason. Change them to work in the "section" section instead and be careful to also change "cores" to "sections". Make sure to also catch "Core", "CoReS" and similar. There are a few instances that actually want to work with a real "core" config such as `core.bare` or `core.editor`. After this, it's clearer that they work with "core" for a reason. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04t1300: remove duplicate test for `--file no-such-file`Libravatar Martin Ågren1-6/+2
We test that we can handle `git config --file symlink` and the error case of `git config --file symlink-to-missing-file`. For good measure, we also throw in a test to check that we correctly handle referencing a missing regular file. But we have such a test earlier in this script. They both check that we fail to use `--file no-such-file --list`. Drop the latter of these and keep the one that is in the general area where we test `--file` and `GIT_CONFIG`. The one we're dropping also checks that we can't even get a specific key from the missing file -- let's make sure we check that in the test we keep. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04t1300: remove duplicate test for `--file ../foo`Libravatar Martin Ågren1-4/+0
We have two tests for checking that we can handle `git config --file ../other-config ...`. One, using `--file`, was introduced in 65807ee697 ("builtin-config: Fix crash when using "-f <relative path>" from non-root dir", 2010-01-26), then another, using `GIT_CONFIG`, came about in 270a34438b ("config: stop using config_exclusive_filename", 2012-02-16). The latter of these was then converted to use `--file` in f7e8714101 ("t: prefer "git config --file" to GIT_CONFIG", 2014-03-20). Both where then simplified in a5db0b77b9 ("t1300: extract and use test_cmp_config()", 2018-10-21). These two tests differ slightly in the order of the options used, but other than that, they are identical. Let's drop one. As noted in f7e8714101, we do still have a test for `GIT_CONFIG` and it shares the implementation with `--file`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: implement --fixed-value with --get*Libravatar Derrick Stolee1-0/+22
The config builtin does its own regex matching of values for the --get, --get-all, and --get-regexp modes. Plumb the existing 'flags' parameter to the get_value() method so we can initialize the value-pattern argument as a fixed string instead of a regex pattern. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: plumb --fixed-value into config APILibravatar Derrick Stolee1-0/+50
The git_config_set_multivar_in_file_gently() and related methods now take a 'flags' bitfield, so add a new bit representing the --fixed-value option from 'git config'. This alters the purpose of the value_pattern parameter to be an exact string match. This requires some initialization changes in git_config_set_multivar_in_file_gently() and a new strcmp() call in the matches() method. The new CONFIG_FLAGS_FIXED_VALUE flag is initialized in builtin/config.c based on the --fixed-value option, and that needs to be updated in several callers. This patch only affects some of the modes of 'git config', and the rest will be completed in the next change. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: add --fixed-value option, un-implementedLibravatar Derrick Stolee1-0/+24
The 'git config' builtin takes a 'value-pattern' parameter for several actions. This can cause confusion when expecting exact value matches instead of regex matches, especially when the input string contains metacharacters. While callers can escape the patterns themselves, it would be more friendly to allow an argument to disable the pattern matching in favor of an exact string match. Add a new '--fixed-value' option that does not currently change the behavior. The implementation will be filled in by later changes for each appropriate action. For now, check and test that --fixed-value will abort the command when included with an incompatible action or without a 'value-pattern' argument. The name '--fixed-value' was chosen over something simpler like '--fixed' because some commands allow regular expressions on the key in addition to the value. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25t1300: add test for --replace-all with value-patternLibravatar Derrick Stolee1-0/+14
The --replace-all option was added in 4ddba79d (git-config-set: add more options) but was not tested along with the 'value-pattern' parameter. Since we will be updating this option to optionally treat 'value-pattern' as a fixed string, let's add a test here that documents the current behavior. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25t1300: test "set all" mode with value-patternLibravatar Derrick Stolee1-0/+39
Without additional modifiers, 'git config <key> <value>' attempts to set a single value in the .git/config file. When the value-pattern parameter is supplied, this command behaves in a non-trivial manner. Consider 'git config <key> <value> <value-pattern>'. The expected behavior is as follows: 1. If there are multiple existing values that match 'value-pattern', then the command fails. Users should use --replace-all instead. 2. If there is no existing values match 'value-pattern', then the 'key=value' pair is appended, making this 'key' a multi-valued config setting. 3. If there is one existing value that matches 'value-pattern', then the new config has one entry where 'key=value'. Add a test that demonstrates these options. Break from the existing pattern in t1300-config.sh to use 'git config --file=<file>' instead of modifying .git/config directly to prevent possibly incompatible repo states. Also use 'git config --file=<file> --list' for config state comparison instead of the config file format. This makes the tests more readable. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t[01]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-5/+5
Carefully excluding t1309, which sees independent development elsewhere at the time of writing, we transition above-mentioned tests to the default branch name `main`. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -e 's/naster/nain/g' -- t[01]*.sh && git checkout HEAD -- t1309\*) Note that t5533 contains a variation of the name `master` (`naster`) that we rename here, too. This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09config: complain about --worktree outside of a git repoLibravatar Matheus Tavares1-5/+8
Running `git config --worktree` outside of a git repository hits a BUG() when trying to enumerate the worktrees. Let's catch this error earlier and die() with a friendlier message. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-05Merge branch 'bc/wildcard-credential'Libravatar Junio C Hamano1-0/+6
A configuration element used for credential subsystem can now use wildcard pattern to specify for which set of URLs the entry applies. * bc/wildcard-credential: credential: allow wildcard patterns when matching config credential: use the last matching username in the config t0300: add tests for some additional cases t1300: add test for urlmatch with multiple wildcards mailmap: add an additional email address for brian m. carlson
2020-02-20t1300: add test for urlmatch with multiple wildcardsLibravatar brian m. carlson1-0/+6
Our urlmatch code handles multiple wildcards, but we don't currently have a test that checks this code path. Add a test that we handle this case correctly to avoid any regressions. Signed-off-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-10config: add '--show-scope' to print the scope of a config valueLibravatar Matthew Rogers1-0/+59
When a user queries config values with --show-origin, often it's difficult to determine what the actual "scope" (local, global, etc.) of a given value is based on just the origin file. Teach 'git config' the '--show-scope' option to print the scope of all displayed config values. Note that we should never see anything of "submodule" scope as that is only ever used by submodule-config.c when parsing the '.gitmodules' file. Signed-off-by: Matthew Rogers <mattr94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-24t1300: create custom config file without special charactersLibravatar Matthew Rogers1-5/+10
Tests that required a custom configuration file to be created previously used a file with non-alphanumeric characters including escaped double quotes. This is not really necessary for the majority of tests involving custom config files, and decreases test coverage on systems that dissallow such filenames (Windows, etc.). Create two files, one appropriate for testing quoting and one appropriate for general use. Signed-off-by: Matthew Rogers <mattr94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-24t1300: fix over-indented HERE-DOCsLibravatar Matthew Rogers1-84/+84
Prepare for the following patches by removing extraneous indents from HERE-DOCs used in config tests. Signed-off-by: Matthew Rogers <mattr94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-06t: use common $SQ variableLibravatar Denton Liu1-5/+4
In many test scripts, there are bespoke definitions of the single quote that are some variation of this: SQ="'" Define a common $SQ variable in test-lib.sh and replace all usages of these bespoke variables with the common one. This change was done by running `git grep =\"\'\" t/` and `git grep =\\\\\'` and manually changing the resulting definitions and corresponding usages. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13tests: avoid syntax triggering old dash bugLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Avoid a bug in dash that's been fixed ever since its ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first released with dash v0.5.7 in July 2011. This failing test was introduced in 5f9674243d ("config: add --expiry-date", 2017-11-18). This fixes 1/2 tests failing on Debian Lenny & Squeeze. The other failure is due to 1b42f45255 ("git-svn: apply "svn.pathnameencoding" before URL encoding", 2016-02-09). The dash bug is triggered by this test because the heredoc contains a command embedded in "$()" with a "{}" block coming right after it. Refactoring the "$()" to e.g. be a variable that was set earlier will also work around it, but let's instead break up the "EOF" and the "{}". An earlier version of this patch[2] mitigated the issue by breaking the "$()" out of the "{}" block, that worked, but just because it broke up the "EOF" and "{}" block. Putting e.g. "echo &&" between the two would also work. 1. https://git.kernel.org/pub/scm/utils/dash/dash.git/ 2. https://public-inbox.org/git/20181127164253.9832-1-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-22t1300: extract and use test_cmp_config()Libravatar Nguyễn Thái Ngọc Duy1-60/+19
In many config-related tests it's common to check if a config variable has expected value and we want to print the differences when the test fails. Doing it the normal way is three lines of shell code. Let's add a function do to all this (and a little more). This function has uses outside t1300 as well but I'm not going to convert them all. And it will be used in the next commit where per-worktree config feature is introduced. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07t/*: fix ordering of expected/observed argumentsLibravatar Matthew DeVore1-2/+2
Fix various places where the ordering was obviously wrong, meaning it was easy to find with grep. Signed-off-by: Matthew DeVore <matvore@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07tests: standardize pipe placementLibravatar Matthew DeVore1-2/+3
Instead of using a line-continuation and pipe on the second line, take advantage of the shell's implicit line continuation after a pipe character. So for example, instead of some long line \ | next line use some long line | next line And add a blank line before and after the pipe where it aids readability (it usually does). This better matches the coding style documented in Documentation/CodingGuidelines and used in shell scripts elsewhere in the tree. Signed-off-by: Matthew DeVore <matvore@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'sg/test-must-be-empty'Libravatar Junio C Hamano1-4/+1
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'Libravatar SZEDER Gábor1-4/+1
Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-20Merge branch 'sb/config-write-fix'Libravatar Junio C Hamano1-0/+87
Recent update to "git config" broke updating variable in a subsection, which has been corrected. * sb/config-write-fix: git-config: document accidental multi-line setting in deprecated syntax config: fix case sensitive subsection names on writing t1300: document current behavior of setting options
2018-08-08config: fix case sensitive subsection names on writingLibravatar Stefan Beller1-0/+1
A user reported a submodule issue regarding a section mix-up, but it could be boiled down to the following test case: $ git init test && cd test $ git config foo."Bar".key test $ git config foo."bar".key test $ tail -n 3 .git/config [foo "Bar"] key = test key = test Sub sections are case sensitive and we have a test for correctly reading them. However we do not have a test for writing out config correctly with case sensitive subsection names, which is why this went unnoticed in 6ae996f2acf (git_config_set: make use of the config parser's event stream, 2018-04-09) Unfortunately we have to make a distinction between old style configuration that looks like [foo.Bar] key = test and the new quoted style as seen above. The old style is documented as case-agnostic, hence we need to keep 'strncasecmp'; although the resulting setting for the old style config differs from the configuration. That will be fixed in a follow up patch. Reported-by: JP Sugarbroad <jpsugar@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-01t1300: document current behavior of setting optionsLibravatar Stefan Beller1-0/+86
This documents current behavior of the config machinery, when changing the value of some settings. This patch just serves to provide a baseline for the follow up that will fix some issues with the current behavior. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t: use sane_unset() rather than 'unset' with broken &&-chainLibravatar Eric Sunshine1-1/+1
These tests intentionally break the &&-chain after using 'unset' since they don't know if 'unset' will succeed or fail and don't want a local 'unset' failure to fail the test overall. We can do better by using sane_unset(), which can be linked into the &&-chain as usual. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-08Merge branch 'tb/config-default'Libravatar Junio C Hamano1-0/+30
"git config --get" learned the "--default" option, to help the calling script. Building on top of the tb/config-type topic, the "git config" learns "--type=color" type. Taken together, you can do things like "git config --get foo.color --default blue" and get the ANSI color sequence for the color given to foo.color variable, or "blue" if the variable does not exist. * tb/config-default: builtin/config: introduce `color` type specifier config.c: introduce 'git_config_color' to parse ANSI colors builtin/config: introduce `--default`
2018-05-08Merge branch 'tb/config-type'Libravatar Junio C Hamano1-1/+64
The "git config" command uses separate options e.g. "--int", "--bool", etc. to specify what type the caller wants the value to be interpreted as. A new "--type=<typename>" option has been introduced, which would make it cleaner to define new types. * tb/config-type: builtin/config.c: support `--type=<type>` as preferred alias for `--<type>` builtin/config.c: treat type specifiers singularly
2018-05-08Merge branch 'js/empty-config-section-fix'Libravatar Junio C Hamano1-0/+1710
"git config --unset a.b", when "a.b" is the last variable in an otherwise empty section "a", left an empty section "a" behind, and worse yet, a subsequent "git config a.c value" did not reuse that empty shell and instead created a new one. These have been (partially) corrected. * js/empty-config-section-fix: git_config_set: reuse empty sections git config --unset: remove empty sections (in the common case) git_config_set: make use of the config parser's event stream git_config_set: do not use a state machine config_set_store: rename some fields for consistency config: avoid using the global variable `store` config: introduce an optional event stream while parsing t1300: `--unset-all` can leave an empty section behind (bug) t1300: add a few more hairy examples of sections becoming empty t1300: remove unreasonable expectation from TODO t1300: avoid relying on a bug config --replace-all: avoid extra line breaks t1300: demonstrate that --replace-all can "invent" newlines t1300: rename it to reflect that `repo-config` was deprecated git_config_set: fix off-by-two
2018-04-09git_config_set: reuse empty sectionsLibravatar Johannes Schindelin1-1/+1
It can happen quite easily that the last setting in a config section is removed, and to avoid confusion when there are comments in the config about that section, we keep a lone section header, i.e. an empty section. Now that we use the `event_fn` callback, it is easy to add support for re-using empty sections, so let's do that. Note: t5512-ls-remote requires that this change is applied *after* the patch "git config --unset: remove empty sections (in the common case)": without that patch, there would be empty `transfer` and `uploadpack` sections ready for reuse, but in the *wrong* order (and sconsequently, t5512's "overrides work between mixed transfer/upload-pack hideRefs" would fail). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09git config --unset: remove empty sections (in the common case)Libravatar Johannes Schindelin1-2/+2
The original reasoning for not removing section headers upon removal of the last entry went like this: the user could have added comments about the section, or about the entries therein, and if there were other comments there, we would not know whether we should remove them. In particular, a concocted example was presented that looked like this (and was added to t1300): # some generic comment on the configuration file itself # a comment specific to this "section" section. [section] # some intervening lines # that should also be dropped key = value # please be careful when you update the above variable The ideal thing for `git config --unset section.key` in this case would be to leave only the first line behind, because all the other comments are now obsolete. However, this is unfeasible, short of adding a complete Natural Language Processing module to Git, which seems not only a lot of work, but a totally unreasonable feature (for little benefit to most users). Now, the real kicker about this problem is: most users do not edit their config files at all! In their use case, the config looks like this instead: [section] key = value ... and it is totally obvious what should happen if the entry is removed: the entire section should vanish. Let's generalize this observation to this conservative strategy: if we are removing the last entry from a section, and there are no comments inside that section nor surrounding it, then remove the entire section. Otherwise behave as before: leave the now-empty section (including those comments, even ones about the now-deleted entry). We have to be extra careful to handle the case where more than one entry is removed: any subset of them might be the last entries of their respective sections (and if there are no comments in or around that section, the section should be removed, too). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09t1300: `--unset-all` can leave an empty section behind (bug)Libravatar Johannes Schindelin1-0/+11
We already have a test demonstrating that removing the last entry from a config section fails to remove the section header of the now-empty section. The same can happen, of course, if we remove the last entries in one fell swoop. This is *also* a bug, and should be fixed at the same time. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09t1300: add a few more hairy examples of sections becoming emptyLibravatar Johannes Schindelin1-1/+44
During the review of the first iteration of the patch series to remove sections that become empty upon --unset or --unset-all, Jeff King identified a couple of problematic cases with the backtracking approach that was still used then to "look backwards for the section header": https://public-inbox.org/git/20180329213229.GG2939@sigill.intra.peff.net/ This patch adds a couple of concocted examples designed to fool a backtracking parser. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06t1300: remove unreasonable expectation from TODOLibravatar Johannes Schindelin1-1/+20
In https://public-inbox.org/git/7vvc8alzat.fsf@alter.siamese.dyndns.org/ a reasonable patch was made quite a bit less so by changing a test case demonstrating a bug to a test case that demonstrates that we ask for too much: the test case 'unsetting the last key in a section removes header' now expects a future bug fix to be able to determine whether a free-form comment above a section header refers to said section or not. Rather than shooting for the stars (and not even getting off the ground), let's start shooting for something obtainable and be reasonably confident that we *can* get it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06t1300: avoid relying on a bugLibravatar Johannes Schindelin1-0/+2
The test case 'unset with cont. lines' relied on a bug that is about to be fixed: it tests *explicitly* that removing the last entry from a config section leaves an *empty* section behind. Let's fix this test case not to rely on that behavior, simply by preventing the section from becoming empty. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06config --replace-all: avoid extra line breaksLibravatar Johannes Schindelin1-1/+1
When replacing multiple config entries at once, we did not re-set the flag that indicates whether we need to insert a new-line before the new entry. As a consequence, an extra new-line was inserted under certain circumstances. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>