summaryrefslogtreecommitdiff
path: root/t/t1300-config.sh
AgeCommit message (Collapse)AuthorFilesLines
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>