summaryrefslogtreecommitdiff
path: root/t/t1300-config.sh
AgeCommit message (Collapse)AuthorFilesLines
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-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>
2018-04-06t1300: demonstrate that --replace-all can "invent" newlinesLibravatar Johannes Schindelin1-0/+21
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06t1300: rename it to reflect that `repo-config` was deprecatedLibravatar Johannes Schindelin1-0/+1591
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>