2005-11-17 21:50:08 +00:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2005 Johannes Schindelin
|
|
|
|
#
|
|
|
|
|
2007-07-03 05:52:14 +00:00
|
|
|
test_description='Test git config in different settings'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
2020-11-18 23:44:21 +00:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
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-11-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2021-10-30 22:24:23 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2005-11-17 21:50:08 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
2024-03-21 06:06:07 +00:00
|
|
|
test_expect_success 'setup whitespace config' '
|
|
|
|
sed -e "s/^|//" \
|
|
|
|
-e "s/[$]$//" \
|
|
|
|
-e "s/X/ /g" >.git/config <<-\EOF
|
|
|
|
[section]
|
|
|
|
| solid = rock
|
|
|
|
| sparse = big XX blue
|
|
|
|
| sparseAndTail = big XX blue $
|
|
|
|
| sparseAndTailQuoted = "big XX blue "
|
|
|
|
| sparseAndBiggerTail = big XX blue X X
|
|
|
|
| sparseAndBiggerTailQuoted = "big XX blue X X"
|
|
|
|
| sparseAndBiggerTailQuotedPlus = "big XX blue X X"X $
|
|
|
|
| headAndTail = Xbig blue $
|
|
|
|
| headAndTailQuoted = "Xbig blue "
|
|
|
|
| headAndTailQuotedPlus = "Xbig blue " $
|
|
|
|
| annotated = big blueX# to be discarded
|
|
|
|
| annotatedQuoted = "big blue"X# to be discarded
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'no internal whitespace' '
|
|
|
|
echo "rock" >expect &&
|
|
|
|
git config --get section.solid >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'internal whitespace' '
|
|
|
|
echo "big QQ blue" | q_to_tab >expect &&
|
|
|
|
git config --get section.sparse >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'internal and trailing whitespace' '
|
|
|
|
echo "big QQ blue" | q_to_tab >expect &&
|
|
|
|
git config --get section.sparseAndTail >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'internal and trailing whitespace, all quoted' '
|
|
|
|
echo "big QQ blue " | q_to_tab >expect &&
|
|
|
|
git config --get section.sparseAndTailQuoted >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'internal and more trailing whitespace' '
|
|
|
|
echo "big QQ blue" | q_to_tab >expect &&
|
|
|
|
git config --get section.sparseAndBiggerTail >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'internal and more trailing whitespace, all quoted' '
|
|
|
|
echo "big QQ blue Q Q" | q_to_tab >expect &&
|
|
|
|
git config --get section.sparseAndBiggerTailQuoted >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'internal and more trailing whitespace, not all quoted' '
|
|
|
|
echo "big QQ blue Q Q" | q_to_tab >expect &&
|
|
|
|
git config --get section.sparseAndBiggerTailQuotedPlus >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'leading and trailing whitespace' '
|
|
|
|
echo "big blue" >expect &&
|
|
|
|
git config --get section.headAndTail >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'leading and trailing whitespace, all quoted' '
|
|
|
|
echo "Qbig blue " | q_to_tab >expect &&
|
|
|
|
git config --get section.headAndTailQuoted >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'leading and trailing whitespace, not all quoted' '
|
|
|
|
echo "Qbig blue " | q_to_tab >expect &&
|
|
|
|
git config --get section.headAndTailQuotedPlus >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'inline comment' '
|
|
|
|
echo "big blue" >expect &&
|
|
|
|
git config --get section.annotated >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'inline comment, quoted' '
|
|
|
|
echo "big blue" >expect &&
|
|
|
|
git config --get section.annotatedQuoted >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'clear default config' '
|
|
|
|
rm -f .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
2021-01-03 09:36:48 +00:00
|
|
|
[section]
|
2005-11-17 21:50:08 +00:00
|
|
|
penguin = little blue
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'initial' '
|
2021-01-03 09:36:48 +00:00
|
|
|
git config section.penguin "little blue" &&
|
2011-10-12 18:29:20 +00:00
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
2021-01-03 09:36:48 +00:00
|
|
|
[section]
|
2005-11-17 21:50:08 +00:00
|
|
|
penguin = little blue
|
|
|
|
Movie = BadPhysics
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'mixed case' '
|
2021-01-03 09:36:48 +00:00
|
|
|
git config Section.Movie BadPhysics &&
|
2011-10-12 18:29:20 +00:00
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
2021-01-03 09:36:48 +00:00
|
|
|
[section]
|
2005-11-17 21:50:08 +00:00
|
|
|
penguin = little blue
|
|
|
|
Movie = BadPhysics
|
2021-01-03 09:36:48 +00:00
|
|
|
[Sections]
|
2005-11-17 21:50:08 +00:00
|
|
|
WhatEver = Second
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'similar section' '
|
2021-01-03 09:36:48 +00:00
|
|
|
git config Sections.WhatEver Second &&
|
2011-10-12 18:29:20 +00:00
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
2021-01-03 09:36:48 +00:00
|
|
|
[section]
|
2005-11-17 21:50:08 +00:00
|
|
|
penguin = little blue
|
|
|
|
Movie = BadPhysics
|
|
|
|
UPPERCASE = true
|
2021-01-03 09:36:48 +00:00
|
|
|
[Sections]
|
2005-11-17 21:50:08 +00:00
|
|
|
WhatEver = Second
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'uppercase section' '
|
2021-01-03 09:36:48 +00:00
|
|
|
git config SECTION.UPPERCASE true &&
|
2011-10-12 18:29:20 +00:00
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'replace with non-match' '
|
2021-01-03 09:36:48 +00:00
|
|
|
git config section.penguin kingpin !blue
|
2012-10-23 18:59:26 +00:00
|
|
|
'
|
2005-11-20 12:24:18 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'replace with non-match (actually matching)' '
|
2021-01-03 09:36:48 +00:00
|
|
|
git config section.penguin "very blue" !kingpin
|
2012-10-23 18:59:26 +00:00
|
|
|
'
|
2005-11-20 12:24:18 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
2021-01-03 09:36:48 +00:00
|
|
|
[section]
|
2005-11-20 12:24:18 +00:00
|
|
|
Movie = BadPhysics
|
|
|
|
UPPERCASE = true
|
config: fix --comment formatting
When git adds comments itself (like "rebase -i" todo list and
"commit -e" log message editor), it always gives a comment
introducer "#" followed by a Space before the message, except for
the recently introduced "git config --comment", where the users are
forced to say " this is my comment" if they want to add their
comment in this usual format; otherwise their comment string will
end up without a space after the "#".
Make it more ergonomic, while keeping it possible to also use this
unusual style, by massaging the comment string at the UI layer with
a set of simple rules:
* If the given comment string begins with '#', it is passed intact.
* Otherwise, "# " is prefixed.
* A string with LF in it cannot be used as a comment string.
Right now there is only one "front-end" that accepts end-user
comment string and calls the underlying machinery to add or modify
configuration file with comments, but to make sure that the future
callers perform similar massaging as they see fit, add a sanity
check logic in git_config_set_multivar_in_file_gently(), which is
the single choke point in the codepaths that consumes the comment
string.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-15 19:43:58 +00:00
|
|
|
penguin = gentoo # Pygoscelis papua
|
|
|
|
disposition = peckish # find fish
|
|
|
|
foo = bar #abc
|
config: allow tweaking whitespace between value and comment
Extending the previous step, this allows the whitespace placed after
the value before the "# comment message" to be tweaked by tweaking
the preprocessing rule to:
* If the given comment string begins with one or more whitespace
characters followed by '#', it is passed intact.
* If the given comment string begins with '#', a Space is
prepended.
* Otherwise, " # " (Space, '#', Space) is prefixed.
* A string with LF in it cannot be used as a comment string.
Unlike the previous step, which unconditionally added a space after
the value before writing the "# comment string", because the above
preprocessing already gives a whitespace before the '#', the
resulting string is written immediately after copying the value.
And the sanity checking rule becomes
* comment string after the above massaging that comes into
git_config_set_multivar_in_file_gently() must
- begin with zero or more whitespace characters followed by '#'.
- not have a LF in it.
I personally think this is over-engineered, but since I thought
things through anyway, here it is in the patch form. The logic to
tweak end-user supplied comment string is encapsulated in a new
helper function, git_config_prepare_comment_string(), so if new
front-end callers would want to use the same massaging rules, it is
easily reused.
Unfortunately I do not think of a way to tweak the preprocessing
rules further to optionally allow having no blank after the value,
i.e. to produce
[section]
variable = value#comment
(which is a valid way to say section.variable=value, by the way)
without sacrificing the ergonomics for the more usual case, so this
time I really stop here.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-15 22:26:40 +00:00
|
|
|
spsp = value # and comment
|
|
|
|
htsp = value # and comment
|
2021-01-03 09:36:48 +00:00
|
|
|
[Sections]
|
2005-11-20 12:24:18 +00:00
|
|
|
WhatEver = Second
|
|
|
|
EOF
|
|
|
|
|
2024-03-12 21:47:00 +00:00
|
|
|
test_expect_success 'append comments' '
|
|
|
|
git config --replace-all --comment="Pygoscelis papua" section.penguin gentoo &&
|
|
|
|
git config --comment="find fish" section.disposition peckish &&
|
config: fix --comment formatting
When git adds comments itself (like "rebase -i" todo list and
"commit -e" log message editor), it always gives a comment
introducer "#" followed by a Space before the message, except for
the recently introduced "git config --comment", where the users are
forced to say " this is my comment" if they want to add their
comment in this usual format; otherwise their comment string will
end up without a space after the "#".
Make it more ergonomic, while keeping it possible to also use this
unusual style, by massaging the comment string at the UI layer with
a set of simple rules:
* If the given comment string begins with '#', it is passed intact.
* Otherwise, "# " is prefixed.
* A string with LF in it cannot be used as a comment string.
Right now there is only one "front-end" that accepts end-user
comment string and calls the underlying machinery to add or modify
configuration file with comments, but to make sure that the future
callers perform similar massaging as they see fit, add a sanity
check logic in git_config_set_multivar_in_file_gently(), which is
the single choke point in the codepaths that consumes the comment
string.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-15 19:43:58 +00:00
|
|
|
git config --comment="#abc" section.foo bar &&
|
config: allow tweaking whitespace between value and comment
Extending the previous step, this allows the whitespace placed after
the value before the "# comment message" to be tweaked by tweaking
the preprocessing rule to:
* If the given comment string begins with one or more whitespace
characters followed by '#', it is passed intact.
* If the given comment string begins with '#', a Space is
prepended.
* Otherwise, " # " (Space, '#', Space) is prefixed.
* A string with LF in it cannot be used as a comment string.
Unlike the previous step, which unconditionally added a space after
the value before writing the "# comment string", because the above
preprocessing already gives a whitespace before the '#', the
resulting string is written immediately after copying the value.
And the sanity checking rule becomes
* comment string after the above massaging that comes into
git_config_set_multivar_in_file_gently() must
- begin with zero or more whitespace characters followed by '#'.
- not have a LF in it.
I personally think this is over-engineered, but since I thought
things through anyway, here it is in the patch form. The logic to
tweak end-user supplied comment string is encapsulated in a new
helper function, git_config_prepare_comment_string(), so if new
front-end callers would want to use the same massaging rules, it is
easily reused.
Unfortunately I do not think of a way to tweak the preprocessing
rules further to optionally allow having no blank after the value,
i.e. to produce
[section]
variable = value#comment
(which is a valid way to say section.variable=value, by the way)
without sacrificing the ergonomics for the more usual case, so this
time I really stop here.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-15 22:26:40 +00:00
|
|
|
|
|
|
|
git config --comment="and comment" section.spsp value &&
|
|
|
|
git config --comment=" # and comment" section.htsp value &&
|
|
|
|
|
2024-03-12 21:47:00 +00:00
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'Prohibited LF in comment' '
|
|
|
|
test_must_fail git config --comment="a${LF}b" section.k v
|
|
|
|
'
|
2005-11-20 12:24:18 +00:00
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'non-match result' 'test_cmp expect .git/config'
|
2005-11-20 12:24:18 +00:00
|
|
|
|
2011-10-12 18:30:02 +00:00
|
|
|
test_expect_success 'find mixed-case key by canonical name' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_cmp_config Second sections.whatever
|
2011-10-12 18:30:02 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'find mixed-case key by non-canonical name' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_cmp_config Second SeCtIoNs.WhAtEvEr
|
2011-10-12 18:30:02 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subsections are not canonicalized by git-config' '
|
|
|
|
cat >>.git/config <<-\EOF &&
|
|
|
|
[section.SubSection]
|
|
|
|
key = one
|
|
|
|
[section "SubSection"]
|
|
|
|
key = two
|
|
|
|
EOF
|
2018-10-21 14:02:27 +00:00
|
|
|
test_cmp_config one section.subsection.key &&
|
|
|
|
test_cmp_config two section.SubSection.key
|
2011-10-12 18:30:02 +00:00
|
|
|
'
|
2005-11-20 12:24:18 +00:00
|
|
|
|
2023-04-23 13:46:49 +00:00
|
|
|
test_missing_key () {
|
|
|
|
local key="$1" &&
|
|
|
|
local title="$2" &&
|
|
|
|
test_expect_success "value for $title is not printed" '
|
|
|
|
test_must_fail git config "$key" >out 2>err &&
|
|
|
|
test_must_be_empty out &&
|
|
|
|
test_must_be_empty err
|
|
|
|
'
|
|
|
|
}
|
|
|
|
|
|
|
|
test_missing_key 'missingsection.missingkey' 'missing section and missing key'
|
|
|
|
test_missing_key 'missingsection.penguin' 'missing section and existing key'
|
|
|
|
test_missing_key 'section.missingkey' 'existing section and missing key'
|
|
|
|
test_missing_key 'section.MissingSubSection.missingkey' 'missing subsection and missing key'
|
|
|
|
test_missing_key 'section.SubSection.missingkey' 'existing subsection and missing key'
|
|
|
|
test_missing_key 'section.MissingSubSection.key' 'missing subsection and existing key'
|
|
|
|
|
2008-02-11 00:23:03 +00:00
|
|
|
cat > .git/config <<\EOF
|
|
|
|
[alpha]
|
|
|
|
bar = foo
|
|
|
|
[beta]
|
|
|
|
baz = multiple \
|
|
|
|
lines
|
2018-04-03 16:28:18 +00:00
|
|
|
foo = bar
|
2008-02-11 00:23:03 +00:00
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'unset with cont. lines' '
|
|
|
|
git config --unset beta.baz
|
|
|
|
'
|
2008-02-11 00:23:03 +00:00
|
|
|
|
|
|
|
cat > expect <<\EOF
|
|
|
|
[alpha]
|
|
|
|
bar = foo
|
|
|
|
[beta]
|
2018-04-03 16:28:18 +00:00
|
|
|
foo = bar
|
2008-02-11 00:23:03 +00:00
|
|
|
EOF
|
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'unset with cont. lines is correct' 'test_cmp expect .git/config'
|
2008-02-11 00:23:03 +00:00
|
|
|
|
2005-11-17 21:50:08 +00:00
|
|
|
cat > .git/config << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
haha ="beta" # last silly comment
|
2005-11-20 05:52:22 +00:00
|
|
|
haha = hello
|
|
|
|
haha = bello
|
2005-11-17 21:50:08 +00:00
|
|
|
[nextSection] noNewline = ouch
|
|
|
|
EOF
|
|
|
|
|
2005-11-20 05:52:22 +00:00
|
|
|
cp .git/config .git/config2
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'multiple unset' '
|
|
|
|
git config --unset-all beta.haha
|
|
|
|
'
|
2005-11-20 05:52:22 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
[nextSection] noNewline = ouch
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'multiple unset is correct' '
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-20 05:52:22 +00:00
|
|
|
|
2009-03-17 09:46:37 +00:00
|
|
|
cp .git/config2 .git/config
|
|
|
|
|
|
|
|
test_expect_success '--replace-all missing value' '
|
|
|
|
test_must_fail git config --replace-all beta.haha &&
|
|
|
|
test_cmp .git/config2 .git/config
|
|
|
|
'
|
|
|
|
|
|
|
|
rm .git/config2
|
2005-11-20 05:52:22 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success '--replace-all' '
|
|
|
|
git config --replace-all beta.haha gamma
|
|
|
|
'
|
2005-11-20 05:52:22 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
haha = gamma
|
|
|
|
[nextSection] noNewline = ouch
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'all replaced' '
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
haha = alpha
|
|
|
|
[nextSection] noNewline = ouch
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'really mean test' '
|
|
|
|
git config beta.haha alpha &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
haha = alpha
|
|
|
|
[nextSection]
|
|
|
|
nonewline = wow
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'really really mean test' '
|
|
|
|
git config nextsection.nonewline wow &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'get value' '
|
2018-10-21 14:02:27 +00:00
|
|
|
test_cmp_config alpha beta.haha
|
2012-10-23 18:59:26 +00:00
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
[nextSection]
|
|
|
|
nonewline = wow
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'unset' '
|
|
|
|
git config --unset beta.haha &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
[nextSection]
|
|
|
|
nonewline = wow
|
|
|
|
NoNewLine = wow2 for me
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'multivar' '
|
|
|
|
git config nextsection.NoNewLine "wow2 for me" "for me$" &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'non-match' '
|
|
|
|
git config --get nextsection.nonewline !for
|
|
|
|
'
|
2005-11-20 12:24:18 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'non-match value' '
|
2018-10-21 14:02:27 +00:00
|
|
|
test_cmp_config wow --get nextsection.nonewline !for
|
2012-10-23 18:59:26 +00:00
|
|
|
'
|
2005-11-20 12:24:18 +00:00
|
|
|
|
git-config: do not complain about duplicate entries
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-23 20:52:44 +00:00
|
|
|
test_expect_success 'multi-valued get returns final one' '
|
2018-10-21 14:02:27 +00:00
|
|
|
test_cmp_config "wow2 for me" --get nextsection.nonewline
|
2008-02-01 09:50:53 +00:00
|
|
|
'
|
2005-11-20 05:52:22 +00:00
|
|
|
|
2012-10-23 22:05:49 +00:00
|
|
|
test_expect_success 'multi-valued get-all returns all' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
wow
|
|
|
|
wow2 for me
|
|
|
|
EOF
|
|
|
|
git config --get-all nextsection.nonewline >actual &&
|
|
|
|
test_cmp expect actual
|
2012-10-23 18:59:26 +00:00
|
|
|
'
|
2005-11-20 05:52:22 +00:00
|
|
|
|
2005-11-17 21:50:08 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
[nextSection]
|
|
|
|
nonewline = wow3
|
|
|
|
NoNewLine = wow2 for me
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'multivar replace' '
|
|
|
|
git config nextsection.nonewline "wow3" "wow$" &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
2008-02-01 09:50:53 +00:00
|
|
|
test_expect_success 'ambiguous unset' '
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git config --unset nextsection.nonewline
|
2008-02-01 09:50:53 +00:00
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
2008-02-01 09:50:53 +00:00
|
|
|
test_expect_success 'invalid unset' '
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git config --unset somesection.nonewline
|
2008-02-01 09:50:53 +00:00
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
[nextSection]
|
|
|
|
NoNewLine = wow2 for me
|
|
|
|
EOF
|
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'multivar unset' '
|
|
|
|
git config --unset nextsection.nonewline "wow3$" &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
2008-07-12 15:47:52 +00:00
|
|
|
test_expect_success 'invalid key' 'test_must_fail git config inval.2key blabla'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
2007-07-03 05:52:14 +00:00
|
|
|
test_expect_success 'correct key' 'git config 123456.a123 987'
|
2005-11-17 21:50:08 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'hierarchical section' '
|
|
|
|
git config Version.1.2.3eX.Alpha beta
|
|
|
|
'
|
2005-11-20 20:22:19 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[beta] ; silly comment # another comment
|
|
|
|
noIndent= sillyValue ; 'nother silly comment
|
|
|
|
|
|
|
|
# empty line
|
|
|
|
; comment
|
|
|
|
[nextSection]
|
|
|
|
NoNewLine = wow2 for me
|
|
|
|
[123456]
|
|
|
|
a123 = 987
|
2006-05-09 19:24:02 +00:00
|
|
|
[Version "1.2.3eX"]
|
|
|
|
Alpha = beta
|
2005-11-20 20:22:19 +00:00
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'hierarchical section value' '
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2005-11-20 20:22:19 +00:00
|
|
|
|
2006-05-02 12:22:48 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
beta.noindent=sillyValue
|
|
|
|
nextsection.nonewline=wow2 for me
|
|
|
|
123456.a123=987
|
2006-05-15 20:48:22 +00:00
|
|
|
version.1.2.3eX.alpha=beta
|
2006-05-02 12:22:48 +00:00
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'working --list' '
|
|
|
|
git config --list > output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
2010-10-21 14:45:44 +00:00
|
|
|
test_expect_success '--list without repo produces empty output' '
|
|
|
|
git --git-dir=nonexistent config --list >output &&
|
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'
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-19 21:57:25 +00:00
|
|
|
test_must_be_empty output
|
2010-10-21 14:45:44 +00:00
|
|
|
'
|
|
|
|
|
2015-08-10 09:46:06 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
beta.noindent
|
|
|
|
nextsection.nonewline
|
|
|
|
123456.a123
|
|
|
|
version.1.2.3eX.alpha
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success '--name-only --list' '
|
|
|
|
git config --name-only --list >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
2006-05-02 12:22:48 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
beta.noindent sillyValue
|
|
|
|
nextsection.nonewline wow2 for me
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success '--get-regexp' '
|
|
|
|
git config --get-regexp in >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
2006-05-02 12:22:48 +00:00
|
|
|
|
2015-08-10 09:46:06 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
beta.noindent
|
|
|
|
nextsection.nonewline
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success '--name-only --get-regexp' '
|
|
|
|
git config --name-only --get-regexp in >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
2006-12-15 12:39:04 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
wow2 for me
|
|
|
|
wow4 for you
|
|
|
|
EOF
|
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success '--add' '
|
|
|
|
git config --add nextsection.nonewline "wow4 for you" &&
|
|
|
|
git config --get-all nextsection.nonewline > output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
2006-12-15 12:39:04 +00:00
|
|
|
|
2006-03-06 05:23:30 +00:00
|
|
|
cat > .git/config << EOF
|
|
|
|
[novalue]
|
|
|
|
variable
|
2008-02-07 05:23:46 +00:00
|
|
|
[emptyvalue]
|
|
|
|
variable =
|
2006-03-06 05:23:30 +00:00
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'get variable with no value' '
|
|
|
|
git config --get novalue.variable ^$
|
|
|
|
'
|
2006-03-06 05:23:30 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'get variable with empty value' '
|
|
|
|
git config --get emptyvalue.variable ^$
|
|
|
|
'
|
2008-02-07 05:23:46 +00:00
|
|
|
|
2007-06-25 14:03:54 +00:00
|
|
|
echo novalue.variable > expect
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'get-regexp variable with no value' '
|
|
|
|
git config --get-regexp novalue > output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
2007-06-25 14:03:54 +00:00
|
|
|
|
2011-10-10 12:54:51 +00:00
|
|
|
echo 'novalue.variable true' > expect
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'get-regexp --bool variable with no value' '
|
|
|
|
git config --bool --get-regexp novalue > output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
2011-10-10 12:54:51 +00:00
|
|
|
|
2008-02-07 05:23:46 +00:00
|
|
|
echo 'emptyvalue.variable ' > expect
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'get-regexp variable with empty value' '
|
|
|
|
git config --get-regexp emptyvalue > output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
2008-02-07 05:23:46 +00:00
|
|
|
|
|
|
|
echo true > expect
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'get bool variable with no value' '
|
|
|
|
git config --bool novalue.variable > output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
2008-02-07 05:23:46 +00:00
|
|
|
|
|
|
|
echo false > expect
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'get bool variable with empty value' '
|
|
|
|
git config --bool emptyvalue.variable > output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
2008-02-07 05:23:46 +00:00
|
|
|
|
2009-03-07 17:14:04 +00:00
|
|
|
test_expect_success 'no arguments, but no crash' '
|
|
|
|
test_must_fail git config >output 2>&1 &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep usage output
|
2009-03-07 17:14:04 +00:00
|
|
|
'
|
2006-05-02 12:22:48 +00:00
|
|
|
|
2006-05-06 19:43:43 +00:00
|
|
|
cat > .git/config << EOF
|
|
|
|
[a.b]
|
|
|
|
c = d
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[a.b]
|
|
|
|
c = d
|
|
|
|
[a]
|
|
|
|
x = y
|
|
|
|
EOF
|
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'new section is partial match of another' '
|
|
|
|
git config a.x y &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2006-05-06 19:43:43 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
[a.b]
|
|
|
|
c = d
|
|
|
|
[a]
|
|
|
|
x = y
|
|
|
|
b = c
|
|
|
|
[b]
|
|
|
|
x = y
|
|
|
|
EOF
|
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'new variable inserts into proper section' '
|
|
|
|
git config b.x y &&
|
|
|
|
git config a.b c &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2006-05-06 19:43:43 +00:00
|
|
|
|
2014-03-20 23:17:01 +00:00
|
|
|
test_expect_success 'alternative --file (non-existing file should fail)' '
|
2021-01-03 09:36:47 +00:00
|
|
|
test_must_fail git config --file non-existing-config -l &&
|
|
|
|
test_must_fail git config --file non-existing-config test.xyzzy
|
2012-10-23 18:59:26 +00:00
|
|
|
'
|
2007-07-31 10:30:52 +00:00
|
|
|
|
2006-06-19 22:51:58 +00:00
|
|
|
cat > other-config << EOF
|
|
|
|
[ein]
|
|
|
|
bahn = strasse
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
ein.bahn=strasse
|
|
|
|
EOF
|
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'alternative GIT_CONFIG' '
|
2014-02-18 22:58:55 +00:00
|
|
|
GIT_CONFIG=other-config git config --list >output &&
|
2011-10-12 18:29:20 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
2006-06-19 22:51:58 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'alternative GIT_CONFIG (--file)' '
|
2014-02-18 22:58:55 +00:00
|
|
|
git config --file other-config --list >output &&
|
2012-10-23 18:59:26 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
2007-07-31 10:30:52 +00:00
|
|
|
|
2014-02-18 22:58:55 +00:00
|
|
|
test_expect_success 'alternative GIT_CONFIG (--file=-)' '
|
|
|
|
git config --file - --list <other-config >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'setting a value in stdin is an error' '
|
|
|
|
test_must_fail git config --file - some.value foo
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'editing stdin is an error' '
|
|
|
|
test_must_fail git config --file - --edit
|
|
|
|
'
|
|
|
|
|
2010-01-26 15:02:16 +00:00
|
|
|
test_expect_success 'refer config from subdirectory' '
|
|
|
|
mkdir x &&
|
2018-10-21 14:02:27 +00:00
|
|
|
test_cmp_config -C x strasse --file=../other-config --get ein.bahn
|
config: stop using config_exclusive_filename
The git-config command sometimes operates on the default set
of config files (either reading from all, or writing to repo
config), and sometimes operates on a specific file. In the
latter case, we set the magic global config_exclusive_filename,
and the code in config.c does the right thing.
Instead, let's have git-config use the "advanced" variants
of config.c's functions which let it specify an individual
filename (or NULL for the default). This makes the code a
lot more obvious, and fixes two small bugs:
1. A relative path specified by GIT_CONFIG=foo will look
in the wrong directory if we have to chdir as part of
repository setup. We already handle this properly for
"git config -f foo", but the GIT_CONFIG lookup used
config_exclusive_filename directly. By dropping to a
single magic variable, the GIT_CONFIG case now just
works.
2. Calling "git config -f foo --edit" would not respect
core.editor. This is because just before editing, we
called git_config, which would respect the
config_exclusive_filename setting, even though this
particular git_config call was not about looking in the
user's specified file, but rather about loading actual
git config, just as any other git program would.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-16 08:07:32 +00:00
|
|
|
'
|
|
|
|
|
2006-06-19 22:51:58 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
[ein]
|
|
|
|
bahn = strasse
|
|
|
|
[anwohner]
|
|
|
|
park = ausweis
|
|
|
|
EOF
|
|
|
|
|
2014-03-20 23:17:01 +00:00
|
|
|
test_expect_success '--set in alternative file' '
|
|
|
|
git config --file=other-config anwohner.park ausweis &&
|
2011-10-12 18:29:20 +00:00
|
|
|
test_cmp expect other-config
|
|
|
|
'
|
2006-06-19 22:51:58 +00:00
|
|
|
|
2006-12-16 14:14:14 +00:00
|
|
|
cat > .git/config << EOF
|
|
|
|
# Hallo
|
|
|
|
#Bello
|
|
|
|
[branch "eins"]
|
|
|
|
x = 1
|
|
|
|
[branch.eins]
|
|
|
|
y = 1
|
|
|
|
[branch "1 234 blabl/a"]
|
|
|
|
weird
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'rename section' '
|
|
|
|
git config --rename-section branch.eins branch.zwei
|
|
|
|
'
|
2006-12-16 14:14:14 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
# Hallo
|
|
|
|
#Bello
|
|
|
|
[branch "zwei"]
|
|
|
|
x = 1
|
|
|
|
[branch "zwei"]
|
|
|
|
y = 1
|
|
|
|
[branch "1 234 blabl/a"]
|
|
|
|
weird
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'rename succeeded' '
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2006-12-16 14:14:14 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'rename non-existing section' '
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git config --rename-section \
|
|
|
|
branch."world domination" branch.drei
|
2008-02-01 09:50:53 +00:00
|
|
|
'
|
2006-12-16 14:14:14 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'rename succeeded' '
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2006-12-16 14:14:14 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'rename another section' '
|
|
|
|
git config --rename-section branch."1 234 blabl/a" branch.drei
|
|
|
|
'
|
2006-12-16 14:14:14 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
# Hallo
|
|
|
|
#Bello
|
|
|
|
[branch "zwei"]
|
|
|
|
x = 1
|
|
|
|
[branch "zwei"]
|
|
|
|
y = 1
|
|
|
|
[branch "drei"]
|
|
|
|
weird
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'rename succeeded' '
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2009-07-24 21:21:44 +00:00
|
|
|
|
|
|
|
cat >> .git/config << EOF
|
|
|
|
[branch "vier"] z = 1
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'rename a section with a var on the same line' '
|
|
|
|
git config --rename-section branch.vier branch.zwei
|
|
|
|
'
|
2009-07-24 21:21:44 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
# Hallo
|
|
|
|
#Bello
|
|
|
|
[branch "zwei"]
|
|
|
|
x = 1
|
|
|
|
[branch "zwei"]
|
|
|
|
y = 1
|
|
|
|
[branch "drei"]
|
|
|
|
weird
|
|
|
|
[branch "zwei"]
|
|
|
|
z = 1
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'rename succeeded' '
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2006-12-16 14:14:14 +00:00
|
|
|
|
2012-04-26 01:47:14 +00:00
|
|
|
test_expect_success 'renaming empty section name is rejected' '
|
|
|
|
test_must_fail git config --rename-section branch.zwei ""
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'renaming to bogus section is rejected' '
|
|
|
|
test_must_fail git config --rename-section branch.zwei "bogus name"
|
|
|
|
'
|
|
|
|
|
config: avoid fixed-sized buffer when renaming/deleting a section
When renaming (or deleting) a section of configuration, Git uses the
function `git_config_copy_or_rename_section_in_file()` to rewrite the
configuration file after applying the rename or deletion to the given
section.
To do this, Git repeatedly calls `fgets()` to read the existing
configuration data into a fixed size buffer.
When the configuration value under `old_name` exceeds the size of the
buffer, we will call `fgets()` an additional time even if there is no
newline in the configuration file, since our read length is capped at
`sizeof(buf)`.
If the first character of the buffer (after zero or more characters
satisfying `isspace()`) is a '[', Git will incorrectly treat it as
beginning a new section when the original section is being removed. In
other words, a configuration value satisfying this criteria can
incorrectly be considered as a new secftion instead of a variable in the
original section.
Avoid this issue by using a variable-width buffer in the form of a
strbuf rather than a fixed-with region on the stack. A couple of small
points worth noting:
- Using a strbuf will cause us to allocate arbitrary sizes to match
the length of each line. In practice, we don't expect any
reasonable configuration files to have lines that long, and a
bandaid will be introduced in a later patch to ensure that this is
the case.
- We are using strbuf_getwholeline() here instead of strbuf_getline()
in order to match `fgets()`'s behavior of leaving the trailing LF
character on the buffer (as well as a trailing NUL).
This could be changed later, but using strbuf_getwholeline() changes
the least about this function's implementation, so it is picked as
the safest path.
- It is temping to want to replace the loop to skip over characters
matching isspace() at the beginning of the buffer with a convenience
function like `strbuf_ltrim()`. But this is the wrong approach for a
couple of reasons:
First, it involves a potentially large and expensive `memmove()`
which we would like to avoid. Second, and more importantly, we also
*do* want to preserve those spaces to avoid changing the output of
other sections.
In all, this patch is a minimal replacement of the fixed-width buffer in
`git_config_copy_or_rename_section_in_file()` to instead use a `struct
strbuf`.
Reported-by: André Baptista <andre@ethiack.com>
Reported-by: Vítor Pinho <vitor@ethiack.com>
Helped-by: Patrick Steinhardt <ps@pks.im>
Co-authored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2023-04-06 18:07:58 +00:00
|
|
|
test_expect_success 'renaming a section with a long line' '
|
t1300: demonstrate failure when renaming sections with long lines
When renaming a configuration section which has an entry whose length
exceeds the size of our buffer in config.c's implementation of
`git_config_copy_or_rename_section_in_file()`, Git will incorrectly
form a new configuration section with part of the data in the section
being removed.
In this instance, our first configuration file looks something like:
[b]
c = d <spaces> [a] e = f
[a]
g = h
Here, we have two configuration values, "b.c", and "a.g". The value "[a]
e = f" belongs to the configuration value "b.c", and does not form its
own section.
However, when renaming the section 'a' to 'xyz', Git will write back
"[xyz]\ne = f", but "[xyz]" is still attached to the value of "b.c",
which is why "e = f" on its own line becomes a new entry called "b.e".
A slightly different example embeds the section being renamed within
another section.
Demonstrate this failure in a test in t1300, which we will fix in the
following commit.
Co-authored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2023-04-06 15:42:03 +00:00
|
|
|
{
|
|
|
|
printf "[b]\\n" &&
|
|
|
|
printf " c = d %1024s [a] e = f\\n" " " &&
|
|
|
|
printf "[a] g = h\\n"
|
|
|
|
} >y &&
|
|
|
|
git config -f y --rename-section a xyz &&
|
|
|
|
test_must_fail git config -f y b.e
|
|
|
|
'
|
|
|
|
|
config: avoid fixed-sized buffer when renaming/deleting a section
When renaming (or deleting) a section of configuration, Git uses the
function `git_config_copy_or_rename_section_in_file()` to rewrite the
configuration file after applying the rename or deletion to the given
section.
To do this, Git repeatedly calls `fgets()` to read the existing
configuration data into a fixed size buffer.
When the configuration value under `old_name` exceeds the size of the
buffer, we will call `fgets()` an additional time even if there is no
newline in the configuration file, since our read length is capped at
`sizeof(buf)`.
If the first character of the buffer (after zero or more characters
satisfying `isspace()`) is a '[', Git will incorrectly treat it as
beginning a new section when the original section is being removed. In
other words, a configuration value satisfying this criteria can
incorrectly be considered as a new secftion instead of a variable in the
original section.
Avoid this issue by using a variable-width buffer in the form of a
strbuf rather than a fixed-with region on the stack. A couple of small
points worth noting:
- Using a strbuf will cause us to allocate arbitrary sizes to match
the length of each line. In practice, we don't expect any
reasonable configuration files to have lines that long, and a
bandaid will be introduced in a later patch to ensure that this is
the case.
- We are using strbuf_getwholeline() here instead of strbuf_getline()
in order to match `fgets()`'s behavior of leaving the trailing LF
character on the buffer (as well as a trailing NUL).
This could be changed later, but using strbuf_getwholeline() changes
the least about this function's implementation, so it is picked as
the safest path.
- It is temping to want to replace the loop to skip over characters
matching isspace() at the beginning of the buffer with a convenience
function like `strbuf_ltrim()`. But this is the wrong approach for a
couple of reasons:
First, it involves a potentially large and expensive `memmove()`
which we would like to avoid. Second, and more importantly, we also
*do* want to preserve those spaces to avoid changing the output of
other sections.
In all, this patch is a minimal replacement of the fixed-width buffer in
`git_config_copy_or_rename_section_in_file()` to instead use a `struct
strbuf`.
Reported-by: André Baptista <andre@ethiack.com>
Reported-by: Vítor Pinho <vitor@ethiack.com>
Helped-by: Patrick Steinhardt <ps@pks.im>
Co-authored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2023-04-06 18:07:58 +00:00
|
|
|
test_expect_success 'renaming an embedded section with a long line' '
|
t1300: demonstrate failure when renaming sections with long lines
When renaming a configuration section which has an entry whose length
exceeds the size of our buffer in config.c's implementation of
`git_config_copy_or_rename_section_in_file()`, Git will incorrectly
form a new configuration section with part of the data in the section
being removed.
In this instance, our first configuration file looks something like:
[b]
c = d <spaces> [a] e = f
[a]
g = h
Here, we have two configuration values, "b.c", and "a.g". The value "[a]
e = f" belongs to the configuration value "b.c", and does not form its
own section.
However, when renaming the section 'a' to 'xyz', Git will write back
"[xyz]\ne = f", but "[xyz]" is still attached to the value of "b.c",
which is why "e = f" on its own line becomes a new entry called "b.e".
A slightly different example embeds the section being renamed within
another section.
Demonstrate this failure in a test in t1300, which we will fix in the
following commit.
Co-authored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2023-04-06 15:42:03 +00:00
|
|
|
{
|
|
|
|
printf "[b]\\n" &&
|
|
|
|
printf " c = d %1024s [a] [foo] e = f\\n" " " &&
|
|
|
|
printf "[a] g = h\\n"
|
|
|
|
} >y &&
|
|
|
|
git config -f y --rename-section a xyz &&
|
|
|
|
test_must_fail git config -f y foo.e
|
|
|
|
'
|
|
|
|
|
2023-04-12 23:18:28 +00:00
|
|
|
test_expect_success 'renaming a section with an overly-long line' '
|
|
|
|
{
|
|
|
|
printf "[b]\\n" &&
|
|
|
|
printf " c = d %525000s e" " " &&
|
|
|
|
printf "[a] g = h\\n"
|
|
|
|
} >y &&
|
|
|
|
test_must_fail git config -f y --rename-section a xyz 2>err &&
|
2023-03-11 16:54:13 +00:00
|
|
|
grep "refusing to work with overly long line in .y. on line 2" err
|
2023-04-12 23:18:28 +00:00
|
|
|
'
|
|
|
|
|
2007-03-02 20:53:33 +00:00
|
|
|
cat >> .git/config << EOF
|
|
|
|
[branch "zwei"] a = 1 [branch "vier"]
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'remove section' '
|
|
|
|
git config --remove-section branch.zwei
|
|
|
|
'
|
2007-03-02 20:53:33 +00:00
|
|
|
|
|
|
|
cat > expect << EOF
|
|
|
|
# Hallo
|
|
|
|
#Bello
|
|
|
|
[branch "drei"]
|
|
|
|
weird
|
|
|
|
EOF
|
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'section was removed properly' '
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2007-03-02 20:53:33 +00:00
|
|
|
|
2007-05-13 07:12:52 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
[gitcvs]
|
|
|
|
enabled = true
|
|
|
|
dbname = %Ggitcvs2.%a.%m.sqlite
|
|
|
|
[gitcvs "ext"]
|
|
|
|
dbname = %Ggitcvs1.%a.%m.sqlite
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'section ending' '
|
2011-10-19 07:37:06 +00:00
|
|
|
rm -f .git/config &&
|
2007-07-03 05:52:14 +00:00
|
|
|
git config gitcvs.enabled true &&
|
|
|
|
git config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite &&
|
|
|
|
git config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite &&
|
2011-10-12 18:29:20 +00:00
|
|
|
test_cmp expect .git/config
|
2007-05-13 07:12:52 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
2006-12-31 03:13:05 +00:00
|
|
|
test_expect_success numbers '
|
2007-07-03 05:52:14 +00:00
|
|
|
git config kilo.gram 1k &&
|
|
|
|
git config mega.ton 1m &&
|
2012-10-23 18:59:26 +00:00
|
|
|
echo 1024 >expect &&
|
|
|
|
echo 1048576 >>expect &&
|
|
|
|
git config --int --get kilo.gram >actual &&
|
|
|
|
git config --int --get mega.ton >>actual &&
|
|
|
|
test_cmp expect actual
|
2006-12-31 03:13:05 +00:00
|
|
|
'
|
|
|
|
|
git-config: always treat --int as 64-bit internally
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-08 08:40:02 +00:00
|
|
|
test_expect_success '--int is at least 64 bits' '
|
|
|
|
git config giga.watts 121g &&
|
2018-10-21 14:02:27 +00:00
|
|
|
echo >expect &&
|
|
|
|
test_cmp_config 129922760704 --int --get giga.watts
|
git-config: always treat --int as 64-bit internally
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-08 08:40:02 +00:00
|
|
|
'
|
|
|
|
|
2007-12-25 07:18:05 +00:00
|
|
|
test_expect_success 'invalid unit' '
|
|
|
|
git config aninvalid.unit "1auto" &&
|
2018-10-21 14:02:27 +00:00
|
|
|
test_cmp_config 1auto aninvalid.unit &&
|
2012-10-23 18:59:26 +00:00
|
|
|
test_must_fail git config --int --get aninvalid.unit 2>actual &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit" actual
|
2007-12-25 07:18:05 +00:00
|
|
|
'
|
|
|
|
|
2021-02-11 20:30:53 +00:00
|
|
|
test_expect_success 'invalid unit boolean' '
|
|
|
|
git config commit.gpgsign "1true" &&
|
|
|
|
test_cmp_config 1true commit.gpgsign &&
|
|
|
|
test_must_fail git config --bool --get commit.gpgsign 2>actual &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "bad boolean config value .1true. for .commit.gpgsign." actual
|
2021-02-11 20:30:53 +00:00
|
|
|
'
|
|
|
|
|
2017-06-14 11:35:46 +00:00
|
|
|
test_expect_success 'line number is reported correctly' '
|
|
|
|
printf "[bool]\n\tvar\n" >invalid &&
|
|
|
|
test_must_fail git config -f invalid --path bool.var 2>actual &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "line 2" actual
|
2017-06-14 11:35:46 +00:00
|
|
|
'
|
|
|
|
|
2016-02-19 09:16:01 +00:00
|
|
|
test_expect_success 'invalid stdin config' '
|
|
|
|
echo "[broken" | test_must_fail git config --list --file - >output 2>&1 &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "bad config line 1 in standard input" output
|
2016-02-19 09:16:01 +00:00
|
|
|
'
|
|
|
|
|
2007-05-20 22:12:57 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
true
|
|
|
|
false
|
|
|
|
true
|
|
|
|
false
|
|
|
|
true
|
|
|
|
false
|
|
|
|
true
|
|
|
|
false
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success bool '
|
|
|
|
|
2007-07-03 05:52:14 +00:00
|
|
|
git config bool.true1 01 &&
|
|
|
|
git config bool.true2 -1 &&
|
|
|
|
git config bool.true3 YeS &&
|
|
|
|
git config bool.true4 true &&
|
|
|
|
git config bool.false1 000 &&
|
|
|
|
git config bool.false2 "" &&
|
|
|
|
git config bool.false3 nO &&
|
|
|
|
git config bool.false4 FALSE &&
|
2007-05-20 22:12:57 +00:00
|
|
|
rm -f result &&
|
|
|
|
for i in 1 2 3 4
|
|
|
|
do
|
tests: fix broken &&-chains in compound statements
The top-level &&-chain checker built into t/test-lib.sh causes tests to
magically exit with code 117 if the &&-chain is broken. However, it has
the shortcoming that the magic does not work within `{...}` groups,
`(...)` subshells, `$(...)` substitutions, or within bodies of compound
statements, such as `if`, `for`, `while`, `case`, etc. `chainlint.sed`
partly fills in the gap by catching broken &&-chains in `(...)`
subshells, but bugs can still lurk behind broken &&-chains in the other
cases.
Fix broken &&-chains in compound statements in order to reduce the
number of possible lurking bugs.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-09 05:11:06 +00:00
|
|
|
git config --bool --get bool.true$i >>result &&
|
2021-12-09 05:11:12 +00:00
|
|
|
git config --bool --get bool.false$i >>result || return 1
|
2018-05-08 06:59:26 +00:00
|
|
|
done &&
|
2012-10-23 18:59:26 +00:00
|
|
|
test_cmp expect result'
|
2007-05-20 22:12:57 +00:00
|
|
|
|
2008-02-01 09:50:53 +00:00
|
|
|
test_expect_success 'invalid bool (--get)' '
|
2007-05-20 22:12:57 +00:00
|
|
|
|
2007-07-03 05:52:14 +00:00
|
|
|
git config bool.nobool foobar &&
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git config --bool --get bool.nobool'
|
2007-05-20 22:12:57 +00:00
|
|
|
|
2008-02-01 09:50:53 +00:00
|
|
|
test_expect_success 'invalid bool (set)' '
|
2007-06-25 14:00:24 +00:00
|
|
|
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git config --bool bool.nobool foobar'
|
2007-06-25 14:00:24 +00:00
|
|
|
|
|
|
|
cat > expect <<\EOF
|
|
|
|
[bool]
|
|
|
|
true1 = true
|
|
|
|
true2 = true
|
|
|
|
true3 = true
|
|
|
|
true4 = true
|
|
|
|
false1 = false
|
|
|
|
false2 = false
|
|
|
|
false3 = false
|
|
|
|
false4 = false
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'set --bool' '
|
|
|
|
|
2011-10-19 07:37:06 +00:00
|
|
|
rm -f .git/config &&
|
2007-07-03 05:52:14 +00:00
|
|
|
git config --bool bool.true1 01 &&
|
|
|
|
git config --bool bool.true2 -1 &&
|
|
|
|
git config --bool bool.true3 YeS &&
|
|
|
|
git config --bool bool.true4 true &&
|
|
|
|
git config --bool bool.false1 000 &&
|
|
|
|
git config --bool bool.false2 "" &&
|
|
|
|
git config --bool bool.false3 nO &&
|
|
|
|
git config --bool bool.false4 FALSE &&
|
2012-10-23 18:59:26 +00:00
|
|
|
test_cmp expect .git/config'
|
2007-06-25 14:00:24 +00:00
|
|
|
|
|
|
|
cat > expect <<\EOF
|
|
|
|
[int]
|
|
|
|
val1 = 1
|
|
|
|
val2 = -1
|
|
|
|
val3 = 5242880
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'set --int' '
|
|
|
|
|
2011-10-19 07:37:06 +00:00
|
|
|
rm -f .git/config &&
|
2007-07-03 05:52:14 +00:00
|
|
|
git config --int int.val1 01 &&
|
|
|
|
git config --int int.val2 -1 &&
|
|
|
|
git config --int int.val3 5m &&
|
2012-10-23 18:59:26 +00:00
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2007-06-25 14:00:24 +00:00
|
|
|
|
2012-10-23 18:59:26 +00:00
|
|
|
test_expect_success 'get --bool-or-int' '
|
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
[bool]
|
|
|
|
true1
|
2008-04-13 19:11:11 +00:00
|
|
|
true2 = true
|
2012-10-23 18:59:26 +00:00
|
|
|
false = false
|
|
|
|
[int]
|
2008-04-13 19:11:11 +00:00
|
|
|
int1 = 0
|
|
|
|
int2 = 1
|
|
|
|
int3 = -1
|
2012-10-23 18:59:26 +00:00
|
|
|
EOF
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
true
|
|
|
|
true
|
|
|
|
false
|
|
|
|
0
|
|
|
|
1
|
|
|
|
-1
|
|
|
|
EOF
|
|
|
|
{
|
|
|
|
git config --bool-or-int bool.true1 &&
|
|
|
|
git config --bool-or-int bool.true2 &&
|
|
|
|
git config --bool-or-int bool.false &&
|
|
|
|
git config --bool-or-int int.int1 &&
|
|
|
|
git config --bool-or-int int.int2 &&
|
|
|
|
git config --bool-or-int int.int3
|
|
|
|
} >actual &&
|
|
|
|
test_cmp expect actual
|
2008-04-13 19:11:11 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
cat >expect <<\EOF
|
|
|
|
[bool]
|
|
|
|
true1 = true
|
|
|
|
false1 = false
|
|
|
|
true2 = true
|
|
|
|
false2 = false
|
|
|
|
[int]
|
|
|
|
int1 = 0
|
|
|
|
int2 = 1
|
|
|
|
int3 = -1
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'set --bool-or-int' '
|
2011-10-19 07:37:06 +00:00
|
|
|
rm -f .git/config &&
|
2008-04-13 19:11:11 +00:00
|
|
|
git config --bool-or-int bool.true1 true &&
|
|
|
|
git config --bool-or-int bool.false1 false &&
|
|
|
|
git config --bool-or-int bool.true2 yes &&
|
|
|
|
git config --bool-or-int bool.false2 no &&
|
|
|
|
git config --bool-or-int int.int1 0 &&
|
|
|
|
git config --bool-or-int int.int2 1 &&
|
|
|
|
git config --bool-or-int int.int3 -1 &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
|
|
|
|
2009-12-30 16:51:53 +00:00
|
|
|
cat >expect <<\EOF
|
|
|
|
[path]
|
|
|
|
home = ~/
|
|
|
|
normal = /dev/null
|
|
|
|
trailingtilde = foo~
|
|
|
|
EOF
|
|
|
|
|
2014-07-21 22:09:27 +00:00
|
|
|
test_expect_success !MINGW 'set --path' '
|
2011-10-19 07:37:06 +00:00
|
|
|
rm -f .git/config &&
|
2009-12-30 16:51:53 +00:00
|
|
|
git config --path path.home "~/" &&
|
|
|
|
git config --path path.normal "/dev/null" &&
|
|
|
|
git config --path path.trailingtilde "foo~" &&
|
|
|
|
test_cmp expect .git/config'
|
|
|
|
|
2014-07-21 22:09:27 +00:00
|
|
|
if test_have_prereq !MINGW && test "${HOME+set}"
|
2010-07-26 15:06:51 +00:00
|
|
|
then
|
|
|
|
test_set_prereq HOMEVAR
|
|
|
|
fi
|
|
|
|
|
2009-12-30 16:51:53 +00:00
|
|
|
cat >expect <<EOF
|
|
|
|
$HOME/
|
|
|
|
/dev/null
|
|
|
|
foo~
|
|
|
|
EOF
|
|
|
|
|
2010-07-26 15:06:51 +00:00
|
|
|
test_expect_success HOMEVAR 'get --path' '
|
2009-12-30 16:51:53 +00:00
|
|
|
git config --get --path path.home > result &&
|
|
|
|
git config --get --path path.normal >> result &&
|
|
|
|
git config --get --path path.trailingtilde >> result &&
|
|
|
|
test_cmp expect result
|
|
|
|
'
|
|
|
|
|
2010-07-26 15:06:51 +00:00
|
|
|
cat >expect <<\EOF
|
|
|
|
/dev/null
|
|
|
|
foo~
|
|
|
|
EOF
|
|
|
|
|
2014-07-21 22:09:27 +00:00
|
|
|
test_expect_success !MINGW 'get --path copes with unset $HOME' '
|
2010-07-26 15:06:51 +00:00
|
|
|
(
|
2018-07-02 00:23:43 +00:00
|
|
|
sane_unset HOME &&
|
2010-07-26 15:06:51 +00:00
|
|
|
test_must_fail git config --get --path path.home \
|
|
|
|
>result 2>msg &&
|
|
|
|
git config --get --path path.normal >>result &&
|
|
|
|
git config --get --path path.trailingtilde >>result
|
|
|
|
) &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "[Ff]ailed to expand.*~/" msg &&
|
2010-07-26 15:06:51 +00:00
|
|
|
test_cmp expect result
|
|
|
|
'
|
|
|
|
|
2012-11-15 18:10:01 +00:00
|
|
|
test_expect_success 'get --path barfs on boolean variable' '
|
|
|
|
echo "[path]bool" >.git/config &&
|
|
|
|
test_must_fail git config --get --path path.bool
|
|
|
|
'
|
|
|
|
|
2017-11-18 02:27:27 +00:00
|
|
|
test_expect_success 'get --expiry-date' '
|
|
|
|
rel="3.weeks.5.days.00:00" &&
|
|
|
|
rel_out="$rel ->" &&
|
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
[date]
|
|
|
|
valid1 = "3.weeks.5.days 00:00"
|
|
|
|
valid2 = "Fri Jun 4 15:46:55 2010"
|
|
|
|
valid3 = "2017/11/11 11:11:11PM"
|
|
|
|
valid4 = "2017/11/10 09:08:07 PM"
|
|
|
|
valid5 = "never"
|
|
|
|
invalid1 = "abc"
|
|
|
|
EOF
|
|
|
|
cat >expect <<-EOF &&
|
2018-03-24 07:44:36 +00:00
|
|
|
$(test-tool date timestamp $rel)
|
2017-11-18 02:27:27 +00:00
|
|
|
1275666415
|
|
|
|
1510441871
|
|
|
|
1510348087
|
|
|
|
0
|
|
|
|
EOF
|
2019-02-13 11:59:51 +00:00
|
|
|
: "work around heredoc parsing bug fixed in dash 0.5.7 (in ec2c84d)" &&
|
2017-11-18 02:27:27 +00:00
|
|
|
{
|
tests: fix broken &&-chains in `{...}` groups
The top-level &&-chain checker built into t/test-lib.sh causes tests to
magically exit with code 117 if the &&-chain is broken. However, it has
the shortcoming that the magic does not work within `{...}` groups,
`(...)` subshells, `$(...)` substitutions, or within bodies of compound
statements, such as `if`, `for`, `while`, `case`, etc. `chainlint.sed`
partly fills in the gap by catching broken &&-chains in `(...)`
subshells, but bugs can still lurk behind broken &&-chains in the other
cases.
Fix broken &&-chains in `{...}` groups in order to reduce the number of
possible lurking bugs.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-09 05:11:08 +00:00
|
|
|
echo "$rel_out $(git config --expiry-date date.valid1)" &&
|
2017-11-18 02:27:27 +00:00
|
|
|
git config --expiry-date date.valid2 &&
|
|
|
|
git config --expiry-date date.valid3 &&
|
|
|
|
git config --expiry-date date.valid4 &&
|
|
|
|
git config --expiry-date date.valid5
|
|
|
|
} >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
test_must_fail git config --expiry-date date.invalid1
|
|
|
|
'
|
|
|
|
|
2018-04-10 00:18:31 +00:00
|
|
|
test_expect_success 'get --type=color' '
|
|
|
|
rm .git/config &&
|
|
|
|
git config foo.color "red" &&
|
|
|
|
git config --get --type=color foo.color >actual.raw &&
|
|
|
|
test_decode_color <actual.raw >actual &&
|
|
|
|
echo "<RED>" >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
cat >expect << EOF
|
|
|
|
[foo]
|
|
|
|
color = red
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'set --type=color' '
|
|
|
|
rm .git/config &&
|
|
|
|
git config --type=color foo.color "red" &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'get --type=color barfs on non-color' '
|
|
|
|
echo "[foo]bar=not-a-color" >.git/config &&
|
|
|
|
test_must_fail git config --get --type=color foo.bar
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'set --type=color barfs on non-color' '
|
|
|
|
test_must_fail git config --type=color foo.color "not-a-color" 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "cannot parse color" error
|
2018-04-10 00:18:31 +00:00
|
|
|
'
|
|
|
|
|
2007-01-09 05:27:41 +00:00
|
|
|
cat > expect << EOF
|
|
|
|
[quote]
|
|
|
|
leading = " test"
|
|
|
|
ending = "test "
|
|
|
|
semicolon = "test;test"
|
|
|
|
hash = "test#test"
|
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'quoting' '
|
2011-10-19 07:37:06 +00:00
|
|
|
rm -f .git/config &&
|
2011-10-12 18:29:20 +00:00
|
|
|
git config quote.leading " test" &&
|
|
|
|
git config quote.ending "test " &&
|
|
|
|
git config quote.semicolon "test;test" &&
|
|
|
|
git config quote.hash "test#test" &&
|
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
2007-01-09 05:27:41 +00:00
|
|
|
|
2008-02-01 09:50:53 +00:00
|
|
|
test_expect_success 'key with newline' '
|
2008-07-12 15:47:52 +00:00
|
|
|
test_must_fail git config "key.with
|
2008-02-01 09:50:53 +00:00
|
|
|
newline" 123'
|
2007-01-20 01:25:37 +00:00
|
|
|
|
2007-01-29 00:16:53 +00:00
|
|
|
test_expect_success 'value with newline' 'git config key.sub value.with\\\
|
2007-01-20 01:25:37 +00:00
|
|
|
newline'
|
|
|
|
|
2007-01-23 12:37:25 +00:00
|
|
|
cat > .git/config <<\EOF
|
|
|
|
[section]
|
|
|
|
; comment \
|
|
|
|
continued = cont\
|
|
|
|
inued
|
|
|
|
noncont = not continued ; \
|
|
|
|
quotecont = "cont;\
|
|
|
|
inued"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat > expect <<\EOF
|
|
|
|
section.continued=continued
|
|
|
|
section.noncont=not continued
|
|
|
|
section.quotecont=cont;inued
|
|
|
|
EOF
|
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success 'value continued on next line' '
|
|
|
|
git config --list > result &&
|
2018-10-05 21:54:04 +00:00
|
|
|
test_cmp expect result
|
2011-10-12 18:29:20 +00:00
|
|
|
'
|
2007-01-23 12:37:25 +00:00
|
|
|
|
2007-06-25 14:03:55 +00:00
|
|
|
cat > .git/config <<\EOF
|
|
|
|
[section "sub=section"]
|
|
|
|
val1 = foo=bar
|
|
|
|
val2 = foo\nbar
|
|
|
|
val3 = \n\n
|
|
|
|
val4 =
|
|
|
|
val5
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat > expect <<\EOF
|
2007-06-27 12:40:41 +00:00
|
|
|
section.sub=section.val1
|
|
|
|
foo=barQsection.sub=section.val2
|
|
|
|
foo
|
|
|
|
barQsection.sub=section.val3
|
2007-06-25 14:03:55 +00:00
|
|
|
|
|
|
|
|
2007-06-27 12:40:41 +00:00
|
|
|
Qsection.sub=section.val4
|
|
|
|
Qsection.sub=section.val5Q
|
2007-06-25 14:03:55 +00:00
|
|
|
EOF
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success '--null --list' '
|
2016-02-17 08:57:46 +00:00
|
|
|
git config --null --list >result.raw &&
|
|
|
|
nul_to_q <result.raw >result &&
|
2011-10-12 18:29:20 +00:00
|
|
|
echo >>result &&
|
|
|
|
test_cmp expect result
|
|
|
|
'
|
2007-06-25 14:03:55 +00:00
|
|
|
|
2011-10-12 18:29:20 +00:00
|
|
|
test_expect_success '--null --get-regexp' '
|
2016-02-17 08:57:46 +00:00
|
|
|
git config --null --get-regexp "val[0-9]" >result.raw &&
|
|
|
|
nul_to_q <result.raw >result &&
|
2011-10-12 18:29:20 +00:00
|
|
|
echo >>result &&
|
|
|
|
test_cmp expect result
|
|
|
|
'
|
2007-06-25 14:03:55 +00:00
|
|
|
|
2024-03-21 06:06:07 +00:00
|
|
|
test_expect_success 'inner whitespace kept verbatim, spaces only' '
|
|
|
|
echo "foo bar" >expect &&
|
|
|
|
git config section.val "foo bar" &&
|
|
|
|
git config --get section.val >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'inner whitespace kept verbatim, horizontal tabs only' '
|
|
|
|
echo "fooQQbar" | q_to_tab >expect &&
|
|
|
|
git config section.val "$(cat expect)" &&
|
|
|
|
git config --get section.val >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'inner whitespace kept verbatim, horizontal tabs and spaces' '
|
|
|
|
echo "foo Q bar" | q_to_tab >expect &&
|
|
|
|
git config section.val "$(cat expect)" &&
|
|
|
|
git config --get section.val >actual &&
|
|
|
|
test_cmp expect actual
|
2009-07-30 11:41:57 +00:00
|
|
|
'
|
|
|
|
|
2009-03-04 21:38:24 +00:00
|
|
|
test_expect_success SYMLINKS 'symlinked configuration' '
|
2007-07-27 05:13:12 +00:00
|
|
|
ln -s notyet myconfig &&
|
2014-03-20 23:17:01 +00:00
|
|
|
git config --file=myconfig test.frotz nitfol &&
|
2007-07-27 05:13:12 +00:00
|
|
|
test -h myconfig &&
|
|
|
|
test -f notyet &&
|
2014-03-20 23:17:01 +00:00
|
|
|
test "z$(git config --file=notyet test.frotz)" = znitfol &&
|
|
|
|
git config --file=myconfig test.xyzzy rezrov &&
|
2007-07-27 05:13:12 +00:00
|
|
|
test -h myconfig &&
|
|
|
|
test -f notyet &&
|
2012-10-23 18:59:26 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
nitfol
|
|
|
|
rezrov
|
|
|
|
EOF
|
|
|
|
{
|
2014-03-20 23:17:01 +00:00
|
|
|
git config --file=notyet test.frotz &&
|
|
|
|
git config --file=notyet test.xyzzy
|
2012-10-23 18:59:26 +00:00
|
|
|
} >actual &&
|
|
|
|
test_cmp expect actual
|
2007-07-27 05:13:12 +00:00
|
|
|
'
|
|
|
|
|
2010-10-21 14:45:44 +00:00
|
|
|
test_expect_success SYMLINKS 'symlink to nonexistent configuration' '
|
|
|
|
ln -s doesnotexist linktonada &&
|
|
|
|
ln -s linktonada linktolinktonada &&
|
2014-03-20 23:15:54 +00:00
|
|
|
test_must_fail git config --file=linktonada --list &&
|
|
|
|
test_must_fail git config --file=linktolinktonada --list
|
2010-10-21 14:45:44 +00:00
|
|
|
'
|
|
|
|
|
2024-01-29 11:07:17 +00:00
|
|
|
test_expect_success 'check split_cmdline return' '
|
|
|
|
test_when_finished "rm -rf repo" &&
|
|
|
|
git init repo &&
|
|
|
|
(
|
|
|
|
cd repo &&
|
|
|
|
git config alias.split-cmdline-fix "echo \"" &&
|
|
|
|
test_must_fail git split-cmdline-fix &&
|
|
|
|
echo foo >foo &&
|
|
|
|
git add foo &&
|
|
|
|
git commit -m "initial commit" &&
|
|
|
|
git config branch.main.mergeoptions "echo \"" &&
|
|
|
|
test_must_fail git merge main
|
|
|
|
)
|
|
|
|
'
|
2008-09-22 15:06:41 +00:00
|
|
|
|
2010-03-26 22:53:57 +00:00
|
|
|
test_expect_success 'git -c "key=value" support' '
|
2012-10-23 18:59:26 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
value
|
|
|
|
value
|
|
|
|
true
|
|
|
|
EOF
|
|
|
|
{
|
2021-01-03 09:36:48 +00:00
|
|
|
git -c section.name=value config section.name &&
|
2012-10-23 18:59:26 +00:00
|
|
|
git -c foo.CamelCase=value config foo.camelcase &&
|
|
|
|
git -c foo.flag config --bool foo.flag
|
|
|
|
} >actual &&
|
|
|
|
test_cmp expect actual &&
|
2021-01-03 09:36:48 +00:00
|
|
|
test_must_fail git -c name=value config section.name
|
2011-01-30 19:40:41 +00:00
|
|
|
'
|
|
|
|
|
2014-08-04 22:40:19 +00:00
|
|
|
# We just need a type-specifier here that cares about the
|
|
|
|
# distinction internally between a NULL boolean and a real
|
|
|
|
# string (because most of git's internal parsers do care).
|
|
|
|
# Using "--path" works, but we do not otherwise care about
|
|
|
|
# its semantics.
|
|
|
|
test_expect_success 'git -c can represent empty string' '
|
|
|
|
echo >expect &&
|
|
|
|
git -c foo.empty= config --path foo.empty >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2011-01-30 19:40:41 +00:00
|
|
|
test_expect_success 'key sanity-checking' '
|
|
|
|
test_must_fail git config foo=bar &&
|
|
|
|
test_must_fail git config foo=.bar &&
|
|
|
|
test_must_fail git config foo.ba=r &&
|
|
|
|
test_must_fail git config foo.1bar &&
|
|
|
|
test_must_fail git config foo."ba
|
|
|
|
z".bar &&
|
2011-02-01 07:13:47 +00:00
|
|
|
test_must_fail git config . false &&
|
|
|
|
test_must_fail git config .foo false &&
|
|
|
|
test_must_fail git config foo. false &&
|
|
|
|
test_must_fail git config .foo. false &&
|
2011-01-30 19:40:41 +00:00
|
|
|
git config foo.bar true &&
|
|
|
|
git config foo."ba =z".bar false
|
2010-03-26 22:53:57 +00:00
|
|
|
'
|
|
|
|
|
2011-05-24 22:50:35 +00:00
|
|
|
test_expect_success 'git -c works with aliases of builtins' '
|
2011-05-24 22:49:55 +00:00
|
|
|
git config alias.checkconfig "-c foo.check=bar config foo.check" &&
|
|
|
|
echo bar >expect &&
|
|
|
|
git checkconfig >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2017-07-14 08:39:38 +00:00
|
|
|
test_expect_success 'aliases can be CamelCased' '
|
2024-01-29 11:07:17 +00:00
|
|
|
test_when_finished "rm -rf repo" &&
|
|
|
|
git init repo &&
|
|
|
|
(
|
|
|
|
cd repo &&
|
|
|
|
test_commit A &&
|
|
|
|
git config alias.CamelCased "rev-parse HEAD" &&
|
|
|
|
git CamelCased >out &&
|
|
|
|
git rev-parse HEAD >expect &&
|
|
|
|
test_cmp expect out
|
|
|
|
)
|
2017-07-14 08:39:29 +00:00
|
|
|
'
|
|
|
|
|
2011-06-09 15:51:36 +00:00
|
|
|
test_expect_success 'git -c does not split values on equals' '
|
|
|
|
echo "value with = in it" >expect &&
|
2021-01-03 09:36:48 +00:00
|
|
|
git -c section.foo="value with = in it" config section.foo >actual &&
|
2011-06-09 15:51:36 +00:00
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2011-06-09 15:52:32 +00:00
|
|
|
test_expect_success 'git -c dies on bogus config' '
|
|
|
|
test_must_fail git -c core.bare=foo rev-parse
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git -c complains about empty key' '
|
|
|
|
test_must_fail git -c "=foo" rev-parse
|
|
|
|
'
|
|
|
|
|
2011-06-09 15:52:43 +00:00
|
|
|
test_expect_success 'git -c complains about empty key and value' '
|
|
|
|
test_must_fail git -c "" rev-parse
|
|
|
|
'
|
|
|
|
|
git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS
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-22 19:50:51 +00:00
|
|
|
test_expect_success 'multiple git -c appends config' '
|
|
|
|
test_config alias.x "!git -c x.two=2 config --get-regexp ^x\.*" &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
x.one 1
|
|
|
|
x.two 2
|
|
|
|
EOF
|
|
|
|
git -c x.one=1 x >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2017-02-23 23:04:40 +00:00
|
|
|
test_expect_success 'last one wins: two level vars' '
|
|
|
|
|
|
|
|
# sec.var and sec.VAR are the same variable, as the first
|
|
|
|
# and the last level of a configuration variable name is
|
|
|
|
# case insensitive.
|
|
|
|
|
|
|
|
echo VAL >expect &&
|
|
|
|
|
|
|
|
git -c sec.var=val -c sec.VAR=VAL config --get sec.var >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git -c SEC.var=val -c sec.var=VAL config --get sec.var >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
git -c sec.var=val -c sec.VAR=VAL config --get SEC.var >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git -c SEC.var=val -c sec.var=VAL config --get sec.VAR >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'last one wins: three level vars' '
|
|
|
|
|
|
|
|
# v.a.r and v.A.r are not the same variable, as the middle
|
|
|
|
# level of a three-level configuration variable name is
|
|
|
|
# case sensitive.
|
|
|
|
|
|
|
|
echo val >expect &&
|
|
|
|
git -c v.a.r=val -c v.A.r=VAL config --get v.a.r >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git -c v.a.r=val -c v.A.r=VAL config --get V.a.R >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
# v.a.r and V.a.R are the same variable, as the first
|
|
|
|
# and the last level of a configuration variable name is
|
|
|
|
# case insensitive.
|
|
|
|
|
|
|
|
echo VAL >expect &&
|
|
|
|
git -c v.a.r=val -c v.a.R=VAL config --get v.a.r >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git -c v.a.r=val -c V.a.r=VAL config --get v.a.r >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git -c v.a.r=val -c v.a.R=VAL config --get V.a.R >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git -c v.a.r=val -c V.a.r=VAL config --get V.a.R >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2018-08-01 19:34:11 +00:00
|
|
|
test_expect_success 'old-fashioned settings are case insensitive' '
|
|
|
|
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
|
|
|
|
|
|
|
|
cat >testConfig_actual <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V.A]
|
|
|
|
r = value1
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
q_to_tab >testConfig_expect <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V.A]
|
|
|
|
Qr = value2
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
git config -f testConfig_actual "v.a.r" value2 &&
|
|
|
|
test_cmp testConfig_expect testConfig_actual &&
|
|
|
|
|
|
|
|
cat >testConfig_actual <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V.A]
|
|
|
|
r = value1
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
q_to_tab >testConfig_expect <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V.A]
|
|
|
|
QR = value2
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
git config -f testConfig_actual "V.a.R" value2 &&
|
|
|
|
test_cmp testConfig_expect testConfig_actual &&
|
|
|
|
|
|
|
|
cat >testConfig_actual <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V.A]
|
|
|
|
r = value1
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
q_to_tab >testConfig_expect <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V.A]
|
|
|
|
r = value1
|
|
|
|
Qr = value2
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
git config -f testConfig_actual "V.A.r" value2 &&
|
|
|
|
test_cmp testConfig_expect testConfig_actual &&
|
|
|
|
|
|
|
|
cat >testConfig_actual <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V.A]
|
|
|
|
r = value1
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
q_to_tab >testConfig_expect <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V.A]
|
|
|
|
r = value1
|
|
|
|
Qr = value2
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
git config -f testConfig_actual "v.A.r" value2 &&
|
|
|
|
test_cmp testConfig_expect testConfig_actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'setting different case sensitive subsections ' '
|
|
|
|
test_when_finished "rm -f testConfig testConfig_expect testConfig_actual" &&
|
|
|
|
|
|
|
|
cat >testConfig_actual <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V "A"]
|
|
|
|
R = v1
|
|
|
|
[K "E"]
|
|
|
|
Y = v1
|
|
|
|
[a "b"]
|
|
|
|
c = v1
|
|
|
|
[d "e"]
|
|
|
|
f = v1
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
q_to_tab >testConfig_expect <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[V "A"]
|
|
|
|
Qr = v2
|
|
|
|
[K "E"]
|
|
|
|
Qy = v2
|
|
|
|
[a "b"]
|
|
|
|
Qc = v2
|
|
|
|
[d "e"]
|
|
|
|
f = v1
|
|
|
|
[d "E"]
|
|
|
|
Qf = v2
|
2018-08-01 19:34:11 +00:00
|
|
|
EOF
|
|
|
|
# exact match
|
|
|
|
git config -f testConfig_actual a.b.c v2 &&
|
|
|
|
# match section and subsection, key is cased differently.
|
|
|
|
git config -f testConfig_actual K.E.y v2 &&
|
|
|
|
# section and key are matched case insensitive, but subsection needs
|
|
|
|
# to match; When writing out new values only the key is adjusted
|
|
|
|
git config -f testConfig_actual v.A.r v2 &&
|
|
|
|
# subsection is not matched:
|
|
|
|
git config -f testConfig_actual d.E.f v2 &&
|
|
|
|
test_cmp testConfig_expect testConfig_actual
|
|
|
|
'
|
|
|
|
|
2017-02-23 23:04:40 +00:00
|
|
|
for VAR in a .a a. a.0b a."b c". a."b c".0d
|
|
|
|
do
|
|
|
|
test_expect_success "git -c $VAR=VAL rejects invalid '$VAR'" '
|
|
|
|
test_must_fail git -c "$VAR=VAL" config -l
|
|
|
|
'
|
|
|
|
done
|
|
|
|
|
|
|
|
for VAR in a.b a."b c".d
|
|
|
|
do
|
|
|
|
test_expect_success "git -c $VAR=VAL works with valid '$VAR'" '
|
|
|
|
echo VAL >expect &&
|
|
|
|
git -c "$VAR=VAL" config --get "$VAR" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
done
|
|
|
|
|
git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS
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-22 19:50:51 +00:00
|
|
|
test_expect_success 'git -c is not confused by empty environment' '
|
|
|
|
GIT_CONFIG_PARAMETERS="" git -c x.one=1 config --list
|
|
|
|
'
|
|
|
|
|
config: parse more robust format in GIT_CONFIG_PARAMETERS
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-12 12:27:06 +00:00
|
|
|
test_expect_success 'GIT_CONFIG_PARAMETERS handles old-style entries' '
|
|
|
|
v="${SQ}key.one=foo${SQ}" &&
|
|
|
|
v="$v ${SQ}key.two=bar${SQ}" &&
|
|
|
|
v="$v ${SQ}key.ambiguous=section.whatever=value${SQ}" &&
|
|
|
|
GIT_CONFIG_PARAMETERS=$v git config --get-regexp "key.*" >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
key.one foo
|
|
|
|
key.two bar
|
|
|
|
key.ambiguous section.whatever=value
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'GIT_CONFIG_PARAMETERS handles new-style entries' '
|
|
|
|
v="${SQ}key.one${SQ}=${SQ}foo${SQ}" &&
|
|
|
|
v="$v ${SQ}key.two${SQ}=${SQ}bar${SQ}" &&
|
|
|
|
v="$v ${SQ}key.ambiguous=section.whatever${SQ}=${SQ}value${SQ}" &&
|
|
|
|
GIT_CONFIG_PARAMETERS=$v git config --get-regexp "key.*" >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
key.one foo
|
|
|
|
key.two bar
|
|
|
|
key.ambiguous=section.whatever value
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'old and new-style entries can mix' '
|
|
|
|
v="${SQ}key.oldone=oldfoo${SQ}" &&
|
|
|
|
v="$v ${SQ}key.newone${SQ}=${SQ}newfoo${SQ}" &&
|
|
|
|
v="$v ${SQ}key.oldtwo=oldbar${SQ}" &&
|
|
|
|
v="$v ${SQ}key.newtwo${SQ}=${SQ}newbar${SQ}" &&
|
|
|
|
GIT_CONFIG_PARAMETERS=$v git config --get-regexp "key.*" >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
key.oldone oldfoo
|
|
|
|
key.newone newfoo
|
|
|
|
key.oldtwo oldbar
|
|
|
|
key.newtwo newbar
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'old and new bools with ambiguous subsection' '
|
|
|
|
v="${SQ}key.with=equals.oldbool${SQ}" &&
|
|
|
|
v="$v ${SQ}key.with=equals.newbool${SQ}=" &&
|
|
|
|
GIT_CONFIG_PARAMETERS=$v git config --get-regexp "key.*" >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
key.with equals.oldbool
|
|
|
|
key.with=equals.newbool
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
sq_dequote: fix extra consumption of source string
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>
2018-02-13 23:41:49 +00:00
|
|
|
test_expect_success 'detect bogus GIT_CONFIG_PARAMETERS' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
env.one one
|
|
|
|
env.two two
|
|
|
|
EOF
|
2019-09-05 22:10:05 +00:00
|
|
|
GIT_CONFIG_PARAMETERS="${SQ}env.one=one${SQ} ${SQ}env.two=two${SQ}" \
|
sq_dequote: fix extra consumption of source string
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>
2018-02-13 23:41:49 +00:00
|
|
|
git config --get-regexp "env.*" >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
cat >expect <<-EOF &&
|
2019-09-05 22:10:05 +00:00
|
|
|
env.one one${SQ}
|
sq_dequote: fix extra consumption of source string
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>
2018-02-13 23:41:49 +00:00
|
|
|
env.two two
|
|
|
|
EOF
|
2019-09-05 22:10:05 +00:00
|
|
|
GIT_CONFIG_PARAMETERS="${SQ}env.one=one${SQ}\\$SQ$SQ$SQ ${SQ}env.two=two${SQ}" \
|
sq_dequote: fix extra consumption of source string
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>
2018-02-13 23:41:49 +00:00
|
|
|
git config --get-regexp "env.*" >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
test_must_fail env \
|
2019-09-05 22:10:05 +00:00
|
|
|
GIT_CONFIG_PARAMETERS="${SQ}env.one=one${SQ}\\$SQ ${SQ}env.two=two${SQ}" \
|
sq_dequote: fix extra consumption of source string
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>
2018-02-13 23:41:49 +00:00
|
|
|
git config --get-regexp "env.*"
|
|
|
|
'
|
|
|
|
|
2021-01-12 12:26:45 +00:00
|
|
|
test_expect_success 'git --config-env=key=envvar support' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
value
|
|
|
|
value
|
2021-04-29 12:55:34 +00:00
|
|
|
value
|
|
|
|
value
|
|
|
|
false
|
2021-01-12 12:26:45 +00:00
|
|
|
false
|
|
|
|
EOF
|
|
|
|
{
|
|
|
|
ENVVAR=value git --config-env=core.name=ENVVAR config core.name &&
|
2021-04-29 12:55:34 +00:00
|
|
|
ENVVAR=value git --config-env core.name=ENVVAR config core.name &&
|
2021-01-12 12:26:45 +00:00
|
|
|
ENVVAR=value git --config-env=foo.CamelCase=ENVVAR config foo.camelcase &&
|
2021-04-29 12:55:34 +00:00
|
|
|
ENVVAR=value git --config-env foo.CamelCase=ENVVAR config foo.camelcase &&
|
|
|
|
ENVVAR= git --config-env=foo.flag=ENVVAR config --bool foo.flag &&
|
|
|
|
ENVVAR= git --config-env foo.flag=ENVVAR config --bool foo.flag
|
2021-01-12 12:26:45 +00:00
|
|
|
} >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2021-04-29 12:55:34 +00:00
|
|
|
test_expect_success 'git --config-env with missing value' '
|
|
|
|
test_must_fail env ENVVAR=value git --config-env 2>error &&
|
|
|
|
grep "no config key given for --config-env" error &&
|
|
|
|
test_must_fail env ENVVAR=value git --config-env config core.name 2>error &&
|
|
|
|
grep "invalid config format: config" error
|
|
|
|
'
|
|
|
|
|
2021-01-12 12:26:45 +00:00
|
|
|
test_expect_success 'git --config-env fails with invalid parameters' '
|
|
|
|
test_must_fail git --config-env=foo.flag config --bool foo.flag 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "invalid config format: foo.flag" error &&
|
2021-01-12 12:26:45 +00:00
|
|
|
test_must_fail git --config-env=foo.flag= config --bool foo.flag 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "missing environment variable name for configuration ${SQ}foo.flag${SQ}" error &&
|
2021-01-12 12:26:45 +00:00
|
|
|
sane_unset NONEXISTENT &&
|
|
|
|
test_must_fail git --config-env=foo.flag=NONEXISTENT config --bool foo.flag 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "missing environment variable ${SQ}NONEXISTENT${SQ} for configuration ${SQ}foo.flag${SQ}" error
|
2021-01-12 12:26:45 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git -c and --config-env work together' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
bar.cmd cmd-value
|
|
|
|
bar.env env-value
|
|
|
|
EOF
|
|
|
|
ENVVAR=env-value git \
|
|
|
|
-c bar.cmd=cmd-value \
|
|
|
|
--config-env=bar.env=ENVVAR \
|
|
|
|
config --get-regexp "^bar.*" >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git -c and --config-env override each other' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
env
|
|
|
|
cmd
|
|
|
|
EOF
|
|
|
|
{
|
|
|
|
ENVVAR=env git -c bar.bar=cmd --config-env=bar.bar=ENVVAR config bar.bar &&
|
|
|
|
ENVVAR=env git --config-env=bar.bar=ENVVAR -c bar.bar=cmd config bar.bar
|
|
|
|
} >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2021-01-12 12:27:01 +00:00
|
|
|
test_expect_success '--config-env handles keys with equals' '
|
|
|
|
echo value=with=equals >expect &&
|
|
|
|
ENVVAR=value=with=equals git \
|
|
|
|
--config-env=section.subsection=with=equals.key=ENVVAR \
|
|
|
|
config section.subsection=with=equals.key >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2021-01-12 12:27:14 +00:00
|
|
|
test_expect_success 'git config handles environment config pairs' '
|
|
|
|
GIT_CONFIG_COUNT=2 \
|
|
|
|
GIT_CONFIG_KEY_0="pair.one" GIT_CONFIG_VALUE_0="foo" \
|
|
|
|
GIT_CONFIG_KEY_1="pair.two" GIT_CONFIG_VALUE_1="bar" \
|
|
|
|
git config --get-regexp "pair.*" >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
pair.one foo
|
|
|
|
pair.two bar
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git config ignores pairs without count' '
|
|
|
|
test_must_fail env GIT_CONFIG_KEY_0="pair.one" GIT_CONFIG_VALUE_0="value" \
|
|
|
|
git config pair.one 2>error &&
|
|
|
|
test_must_be_empty error
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git config ignores pairs exceeding count' '
|
|
|
|
GIT_CONFIG_COUNT=1 \
|
|
|
|
GIT_CONFIG_KEY_0="pair.one" GIT_CONFIG_VALUE_0="value" \
|
|
|
|
GIT_CONFIG_KEY_1="pair.two" GIT_CONFIG_VALUE_1="value" \
|
2023-04-23 13:46:48 +00:00
|
|
|
git config --get-regexp "pair.*" >actual 2>error &&
|
2021-01-12 12:27:14 +00:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
pair.one value
|
|
|
|
EOF
|
2023-04-23 13:46:48 +00:00
|
|
|
test_cmp expect actual &&
|
|
|
|
test_must_be_empty error
|
2021-01-12 12:27:14 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git config ignores pairs with zero count' '
|
|
|
|
test_must_fail env \
|
|
|
|
GIT_CONFIG_COUNT=0 GIT_CONFIG_KEY_0="pair.one" GIT_CONFIG_VALUE_0="value" \
|
2023-04-23 13:46:48 +00:00
|
|
|
git config pair.one 2>error &&
|
2021-01-12 12:27:14 +00:00
|
|
|
test_must_be_empty error
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git config ignores pairs with empty count' '
|
|
|
|
test_must_fail env \
|
|
|
|
GIT_CONFIG_COUNT= GIT_CONFIG_KEY_0="pair.one" GIT_CONFIG_VALUE_0="value" \
|
2023-04-23 13:46:48 +00:00
|
|
|
git config pair.one 2>error &&
|
2021-01-12 12:27:14 +00:00
|
|
|
test_must_be_empty error
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git config fails with invalid count' '
|
|
|
|
test_must_fail env GIT_CONFIG_COUNT=10a git config --list 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "bogus count" error &&
|
2021-01-12 12:27:14 +00:00
|
|
|
test_must_fail env GIT_CONFIG_COUNT=9999999999999999 git config --list 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "too many entries" error
|
2021-01-12 12:27:14 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git config fails with missing config key' '
|
|
|
|
test_must_fail env GIT_CONFIG_COUNT=1 GIT_CONFIG_VALUE_0="value" \
|
|
|
|
git config --list 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "missing config key" error
|
2021-01-12 12:27:14 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git config fails with missing config value' '
|
|
|
|
test_must_fail env GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0="pair.one" \
|
|
|
|
git config --list 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "missing config value" error
|
2021-01-12 12:27:14 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git config fails with invalid config pair key' '
|
|
|
|
test_must_fail env GIT_CONFIG_COUNT=1 \
|
|
|
|
GIT_CONFIG_KEY_0= GIT_CONFIG_VALUE_0=value \
|
|
|
|
git config --list &&
|
|
|
|
test_must_fail env GIT_CONFIG_COUNT=1 \
|
|
|
|
GIT_CONFIG_KEY_0=missing-section GIT_CONFIG_VALUE_0=value \
|
|
|
|
git config --list
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'environment overrides config file' '
|
|
|
|
test_when_finished "rm -f .git/config" &&
|
|
|
|
cat >.git/config <<-EOF &&
|
|
|
|
[pair]
|
|
|
|
one = value
|
|
|
|
EOF
|
|
|
|
GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=pair.one GIT_CONFIG_VALUE_0=override \
|
|
|
|
git config pair.one >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
override
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'GIT_CONFIG_PARAMETERS overrides environment config' '
|
|
|
|
GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=pair.one GIT_CONFIG_VALUE_0=value \
|
|
|
|
GIT_CONFIG_PARAMETERS="${SQ}pair.one=override${SQ}" \
|
|
|
|
git config pair.one >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
override
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'command line overrides environment config' '
|
|
|
|
GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=pair.one GIT_CONFIG_VALUE_0=value \
|
|
|
|
git -c pair.one=override config pair.one >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
override
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
config: stop using config_exclusive_filename
The git-config command sometimes operates on the default set
of config files (either reading from all, or writing to repo
config), and sometimes operates on a specific file. In the
latter case, we set the magic global config_exclusive_filename,
and the code in config.c does the right thing.
Instead, let's have git-config use the "advanced" variants
of config.c's functions which let it specify an individual
filename (or NULL for the default). This makes the code a
lot more obvious, and fixes two small bugs:
1. A relative path specified by GIT_CONFIG=foo will look
in the wrong directory if we have to chdir as part of
repository setup. We already handle this properly for
"git config -f foo", but the GIT_CONFIG lookup used
config_exclusive_filename directly. By dropping to a
single magic variable, the GIT_CONFIG case now just
works.
2. Calling "git config -f foo --edit" would not respect
core.editor. This is because just before editing, we
called git_config, which would respect the
config_exclusive_filename setting, even though this
particular git_config call was not about looking in the
user's specified file, but rather about loading actual
git config, just as any other git program would.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-16 08:07:32 +00:00
|
|
|
test_expect_success 'git config --edit works' '
|
|
|
|
git config -f tmp test.value no &&
|
|
|
|
echo test.value=yes >expect &&
|
|
|
|
GIT_EDITOR="echo [test]value=yes >" git config -f tmp --edit &&
|
|
|
|
git config -f tmp --list >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git config --edit respects core.editor' '
|
|
|
|
git config -f tmp test.value no &&
|
|
|
|
echo test.value=yes >expect &&
|
|
|
|
test_config core.editor "echo [test]value=yes >" &&
|
|
|
|
git config -f tmp --edit &&
|
|
|
|
git config -f tmp --list >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2012-03-09 21:57:54 +00:00
|
|
|
# malformed configuration files
|
|
|
|
test_expect_success 'barf on syntax error' '
|
|
|
|
cat >.git/config <<-\EOF &&
|
2023-04-17 19:10:40 +00:00
|
|
|
# broken key=value
|
2012-03-09 21:57:54 +00:00
|
|
|
[section]
|
|
|
|
key garbage
|
|
|
|
EOF
|
2023-04-17 19:10:41 +00:00
|
|
|
test_must_fail git config --get section.key 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep " line 3 " error
|
2012-03-09 21:57:54 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'barf on incomplete section header' '
|
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
# broken section line
|
|
|
|
[section
|
|
|
|
key = value
|
|
|
|
EOF
|
2023-04-17 19:10:41 +00:00
|
|
|
test_must_fail git config --get section.key 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep " line 2 " error
|
2012-03-09 21:57:54 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'barf on incomplete string' '
|
|
|
|
cat >.git/config <<-\EOF &&
|
2023-04-17 19:10:40 +00:00
|
|
|
# broken value string
|
2012-03-09 21:57:54 +00:00
|
|
|
[section]
|
|
|
|
key = "value string
|
|
|
|
EOF
|
2023-04-17 19:10:41 +00:00
|
|
|
test_must_fail git config --get section.key 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep " line 3 " error
|
2012-03-09 21:57:54 +00:00
|
|
|
'
|
|
|
|
|
2013-07-31 18:14:59 +00:00
|
|
|
test_expect_success 'urlmatch' '
|
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
[http]
|
|
|
|
sslVerify
|
|
|
|
[http "https://weak.example.com"]
|
|
|
|
sslVerify = false
|
|
|
|
cookieFile = /tmp/cookie.txt
|
|
|
|
EOF
|
|
|
|
|
2016-02-28 11:54:35 +00:00
|
|
|
test_expect_code 1 git config --bool --get-urlmatch doesnt.exist https://good.example.com >actual &&
|
|
|
|
test_must_be_empty actual &&
|
|
|
|
|
2013-07-31 18:14:59 +00:00
|
|
|
echo true >expect &&
|
|
|
|
git config --bool --get-urlmatch http.SSLverify https://good.example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo false >expect &&
|
|
|
|
git config --bool --get-urlmatch http.sslverify https://weak.example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
{
|
|
|
|
echo http.cookiefile /tmp/cookie.txt &&
|
|
|
|
echo http.sslverify false
|
|
|
|
} >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://weak.example.com >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
config.c: pass ctx with CLI config
Pass config_context when parsing CLI config. To provide the .kvi member,
refactor out kvi_from_param() from the logic that caches CLI config in
configsets. Now that config_context and config_context.kvi is always
present when config machinery calls config callbacks, plumb "kvi" so
that we can remove all calls of current_config_scope() except for
trace2/*.c (which will be handled in a later commit), and remove all
other current_config_*() (the functions themselves and their calls).
Note that this results in .kvi containing a different, more complete
set of information than the mocked up "struct config_source" in
git_config_from_parameters().
Plumbing "kvi" reveals a few places where we've been doing the wrong
thing:
* git_config_parse_parameter() hasn't been setting config source
information, so plumb "kvi" there too.
* Several sites in builtin/config.c have been calling current_config_*()
functions outside of config callbacks (indirectly, via the
format_config() helper), which means they're reading state that isn't
set correctly:
* "git config --get-urlmatch --show-scope" iterates config to collect
values, but then attempts to display the scope after config
iteration, causing the "unknown" scope to be shown instead of the
config file's scope. It's clear that this wasn't intended: we knew
that "--get-urlmatch" couldn't show config source metadata, which is
why "--show-origin" was marked incompatible with "--get-urlmatch"
when it was introduced [1]. It was most likely a mistake that we
allowed "--show-scope" to sneak through.
Fix this by copying the "kvi" value in the collection phase so that
it can be read back later. This means that we can now support "git
config --get-urlmatch --show-origin", but that is left unchanged
for now.
* "git config --default" doesn't have config source metadata when
displaying the default value, so "--show-scope" also results in
"unknown", and "--show-origin" results in a BUG(). Fix this by
treating the default value as if it came from the command line (e.g.
like we do with "git -c" or "git config --file"), using
kvi_from_param().
[1] https://lore.kernel.org/git/20160205112001.GA13397@sigill.intra.peff.net/
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:25 +00:00
|
|
|
test_expect_success 'urlmatch with --show-scope' '
|
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
[http "https://weak.example.com"]
|
|
|
|
sslVerify = false
|
|
|
|
cookieFile = /tmp/cookie.txt
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
local http.cookiefile /tmp/cookie.txt
|
|
|
|
local http.sslverify false
|
|
|
|
EOF
|
|
|
|
git config --get-urlmatch --show-scope HTTP https://weak.example.com >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2017-01-31 09:01:46 +00:00
|
|
|
test_expect_success 'urlmatch favors more specific URLs' '
|
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
[http "https://example.com/"]
|
|
|
|
cookieFile = /tmp/root.txt
|
|
|
|
[http "https://example.com/subdirectory"]
|
|
|
|
cookieFile = /tmp/subdirectory.txt
|
|
|
|
[http "https://user@example.com/"]
|
|
|
|
cookieFile = /tmp/user.txt
|
|
|
|
[http "https://averylonguser@example.com/"]
|
|
|
|
cookieFile = /tmp/averylonguser.txt
|
2017-01-31 09:01:47 +00:00
|
|
|
[http "https://preceding.example.com"]
|
|
|
|
cookieFile = /tmp/preceding.txt
|
|
|
|
[http "https://*.example.com"]
|
|
|
|
cookieFile = /tmp/wildcard.txt
|
|
|
|
[http "https://*.example.com/wildcardwithsubdomain"]
|
|
|
|
cookieFile = /tmp/wildcardwithsubdomain.txt
|
2020-02-20 02:24:10 +00:00
|
|
|
[http "https://*.example.*"]
|
|
|
|
cookieFile = /tmp/multiwildcard.txt
|
2017-01-31 09:01:47 +00:00
|
|
|
[http "https://trailing.example.com"]
|
|
|
|
cookieFile = /tmp/trailing.txt
|
|
|
|
[http "https://user@*.example.com/"]
|
|
|
|
cookieFile = /tmp/wildcardwithuser.txt
|
|
|
|
[http "https://sub.example.com/"]
|
|
|
|
cookieFile = /tmp/sub.txt
|
2017-01-31 09:01:46 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/root.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/subdirectory.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://example.com/subdirectory >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/subdirectory.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://example.com/subdirectory/nested >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/user.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://user@example.com/ >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/subdirectory.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://averylonguser@example.com/subdirectory >actual &&
|
2017-01-31 09:01:47 +00:00
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/preceding.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://preceding.example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/wildcard.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://wildcard.example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/sub.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://sub.example.com/wildcardwithsubdomain >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/trailing.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://trailing.example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/sub.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://user@sub.example.com >actual &&
|
2020-02-20 02:24:10 +00:00
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.cookiefile /tmp/multiwildcard.txt >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://wildcard.example.org >actual &&
|
2017-01-31 09:01:47 +00:00
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'urlmatch with wildcard' '
|
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
[http]
|
|
|
|
sslVerify
|
|
|
|
[http "https://*.example.com"]
|
|
|
|
sslVerify = false
|
|
|
|
cookieFile = /tmp/cookie.txt
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_code 1 git config --bool --get-urlmatch doesnt.exist https://good.example.com >actual &&
|
|
|
|
test_must_be_empty actual &&
|
|
|
|
|
|
|
|
echo true >expect &&
|
|
|
|
git config --bool --get-urlmatch http.SSLverify https://example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo true >expect &&
|
|
|
|
git config --bool --get-urlmatch http.SSLverify https://good-example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo true >expect &&
|
|
|
|
git config --bool --get-urlmatch http.sslverify https://deep.nested.example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo false >expect &&
|
|
|
|
git config --bool --get-urlmatch http.sslverify https://good.example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
{
|
|
|
|
echo http.cookiefile /tmp/cookie.txt &&
|
|
|
|
echo http.sslverify false
|
|
|
|
} >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://good.example.com >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
echo http.sslverify >expect &&
|
|
|
|
git config --get-urlmatch HTTP https://more.example.com.au >actual &&
|
2017-01-31 09:01:46 +00:00
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
t1300: document some aesthetic failures of the config editor
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>
2013-03-29 19:51:55 +00:00
|
|
|
# good section hygiene
|
git config --unset: remove empty sections (in the common case)
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-09 08:32:24 +00:00
|
|
|
test_expect_success '--unset last key removes section (except if commented)' '
|
t1300: document some aesthetic failures of the config editor
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>
2013-03-29 19:51:55 +00:00
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
# 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
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
# some generic comment on the configuration file itself
|
2018-04-03 16:28:22 +00:00
|
|
|
# a comment specific to this "section" section.
|
|
|
|
[section]
|
|
|
|
# some intervening lines
|
|
|
|
# that should also be dropped
|
|
|
|
|
|
|
|
# please be careful when you update the above variable
|
t1300: document some aesthetic failures of the config editor
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>
2013-03-29 19:51:55 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
git config --unset section.key &&
|
2018-04-03 16:28:22 +00:00
|
|
|
test_cmp expect .git/config &&
|
|
|
|
|
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
[section]
|
|
|
|
key = value
|
|
|
|
[next-section]
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
[next-section]
|
t1300: document some aesthetic failures of the config editor
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>
2013-03-29 19:51:55 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
git config --unset section.key &&
|
2018-04-09 08:31:57 +00:00
|
|
|
test_cmp expect .git/config &&
|
|
|
|
|
|
|
|
q_to_tab >.git/config <<-\EOF &&
|
|
|
|
[one]
|
|
|
|
Qkey = "multiline \
|
|
|
|
QQ# with comment"
|
|
|
|
[two]
|
|
|
|
key = true
|
|
|
|
EOF
|
|
|
|
git config --unset two.key &&
|
|
|
|
! grep two .git/config &&
|
|
|
|
|
|
|
|
q_to_tab >.git/config <<-\EOF &&
|
|
|
|
[one]
|
|
|
|
Qkey = "multiline \
|
|
|
|
QQ# with comment"
|
|
|
|
[one]
|
|
|
|
key = true
|
|
|
|
EOF
|
|
|
|
git config --unset-all one.key &&
|
|
|
|
test_line_count = 0 .git/config &&
|
|
|
|
|
|
|
|
q_to_tab >.git/config <<-\EOF &&
|
|
|
|
[one]
|
|
|
|
Qkey = true
|
|
|
|
Q# a comment not at the start
|
|
|
|
[two]
|
|
|
|
Qkey = true
|
|
|
|
EOF
|
|
|
|
git config --unset two.key &&
|
|
|
|
grep two .git/config &&
|
|
|
|
|
|
|
|
q_to_tab >.git/config <<-\EOF &&
|
|
|
|
[one]
|
|
|
|
Qkey = not [two "subsection"]
|
|
|
|
[two "subsection"]
|
|
|
|
[two "subsection"]
|
|
|
|
Qkey = true
|
|
|
|
[TWO "subsection"]
|
|
|
|
[one]
|
|
|
|
EOF
|
|
|
|
git config --unset two.subsection.key &&
|
|
|
|
test "not [two subsection]" = "$(git config one.key)" &&
|
|
|
|
test_line_count = 3 .git/config
|
t1300: document some aesthetic failures of the config editor
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>
2013-03-29 19:51:55 +00:00
|
|
|
'
|
|
|
|
|
git config --unset: remove empty sections (in the common case)
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-09 08:32:24 +00:00
|
|
|
test_expect_success '--unset-all removes section if empty & uncommented' '
|
2018-04-09 08:32:02 +00:00
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
[section]
|
|
|
|
key = value1
|
|
|
|
key = value2
|
|
|
|
EOF
|
|
|
|
|
|
|
|
git config --unset-all section.key &&
|
|
|
|
test_line_count = 0 .git/config
|
t1300: document some aesthetic failures of the config editor
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>
2013-03-29 19:51:55 +00:00
|
|
|
'
|
|
|
|
|
2018-04-09 08:32:29 +00:00
|
|
|
test_expect_success 'adding a key into an empty section reuses header' '
|
t1300: document some aesthetic failures of the config editor
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>
2013-03-29 19:51:55 +00:00
|
|
|
cat >.git/config <<-\EOF &&
|
|
|
|
[section]
|
|
|
|
EOF
|
|
|
|
|
|
|
|
q_to_tab >expect <<-\EOF &&
|
|
|
|
[section]
|
|
|
|
Qkey = value
|
|
|
|
EOF
|
|
|
|
|
2015-03-20 10:06:44 +00:00
|
|
|
git config section.key value &&
|
t1300: document some aesthetic failures of the config editor
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>
2013-03-29 19:51:55 +00:00
|
|
|
test_cmp expect .git/config
|
|
|
|
'
|
|
|
|
|
2014-05-06 00:17:14 +00:00
|
|
|
test_expect_success POSIXPERM,PERL 'preserves existing permissions' '
|
|
|
|
chmod 0600 .git/config &&
|
|
|
|
git config imap.pass Hunter2 &&
|
|
|
|
perl -e \
|
|
|
|
"die q(badset) if ((stat(q(.git/config)))[2] & 07777) != 0600" &&
|
|
|
|
git config --rename-section imap pop &&
|
|
|
|
perl -e \
|
|
|
|
"die q(badrename) if ((stat(q(.git/config)))[2] & 07777) != 0600"
|
|
|
|
'
|
|
|
|
|
2016-03-23 10:55:13 +00:00
|
|
|
! test_have_prereq MINGW ||
|
|
|
|
HOME="$(pwd)" # convert to Windows path
|
|
|
|
|
2016-02-19 09:16:02 +00:00
|
|
|
test_expect_success 'set up --show-origin tests' '
|
|
|
|
INCLUDE_DIR="$HOME/include" &&
|
|
|
|
mkdir -p "$INCLUDE_DIR" &&
|
|
|
|
cat >"$INCLUDE_DIR"/absolute.include <<-\EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[user]
|
|
|
|
absolute = include
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
cat >"$INCLUDE_DIR"/relative.include <<-\EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[user]
|
|
|
|
relative = include
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
cat >"$HOME"/.gitconfig <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[user]
|
|
|
|
global = true
|
|
|
|
override = global
|
|
|
|
[include]
|
|
|
|
path = "$INCLUDE_DIR/absolute.include"
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
cat >.git/config <<-\EOF
|
2020-01-24 00:21:02 +00:00
|
|
|
[user]
|
|
|
|
local = true
|
|
|
|
override = local
|
|
|
|
[include]
|
|
|
|
path = ../include/relative.include
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-origin with --list' '
|
|
|
|
cat >expect <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
file:$HOME/.gitconfig user.global=true
|
|
|
|
file:$HOME/.gitconfig user.override=global
|
|
|
|
file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
|
|
|
|
file:$INCLUDE_DIR/absolute.include user.absolute=include
|
|
|
|
file:.git/config user.local=true
|
|
|
|
file:.git/config user.override=local
|
|
|
|
file:.git/config include.path=../include/relative.include
|
|
|
|
file:.git/../include/relative.include user.relative=include
|
2021-01-12 12:27:14 +00:00
|
|
|
command line: user.environ=true
|
2020-01-24 00:21:02 +00:00
|
|
|
command line: user.cmdline=true
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
2021-01-12 12:27:14 +00:00
|
|
|
GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=user.environ GIT_CONFIG_VALUE_0=true\
|
|
|
|
git -c user.cmdline=true config --list --show-origin >output &&
|
2016-02-19 09:16:02 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-origin with --list --null' '
|
|
|
|
cat >expect <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
file:$HOME/.gitconfigQuser.global
|
|
|
|
trueQfile:$HOME/.gitconfigQuser.override
|
|
|
|
globalQfile:$HOME/.gitconfigQinclude.path
|
|
|
|
$INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
|
|
|
|
includeQfile:.git/configQuser.local
|
|
|
|
trueQfile:.git/configQuser.override
|
|
|
|
localQfile:.git/configQinclude.path
|
|
|
|
../include/relative.includeQfile:.git/../include/relative.includeQuser.relative
|
|
|
|
includeQcommand line:Quser.cmdline
|
|
|
|
trueQ
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
git -c user.cmdline=true config --null --list --show-origin >output.raw &&
|
|
|
|
nul_to_q <output.raw >output &&
|
|
|
|
# The here-doc above adds a newline that the --null output would not
|
|
|
|
# include. Add it here to make the two comparable.
|
|
|
|
echo >>output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-origin with single file' '
|
|
|
|
cat >expect <<-\EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
file:.git/config user.local=true
|
|
|
|
file:.git/config user.override=local
|
|
|
|
file:.git/config include.path=../include/relative.include
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
git config --local --list --show-origin >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-origin with --get-regexp' '
|
|
|
|
cat >expect <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
file:$HOME/.gitconfig user.global true
|
|
|
|
file:.git/config user.local true
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
git config --show-origin --get-regexp "user\.[g|l].*" >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-origin getting a single key' '
|
|
|
|
cat >expect <<-\EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
file:.git/config local
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
git config --show-origin user.override >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'set up custom config file' '
|
2024-01-29 11:07:17 +00:00
|
|
|
cat >"custom.conf" <<-\EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[user]
|
|
|
|
custom = true
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
2024-01-29 11:07:17 +00:00
|
|
|
CUSTOM_CONFIG_FILE="$(test-tool path-utils real_path custom.conf)"
|
2016-02-19 09:16:02 +00:00
|
|
|
'
|
|
|
|
|
2020-01-24 00:21:03 +00:00
|
|
|
test_expect_success !MINGW 'set up custom config file with special name characters' '
|
|
|
|
WEIRDLY_NAMED_FILE="file\" (dq) and spaces.conf" &&
|
|
|
|
cp "$CUSTOM_CONFIG_FILE" "$WEIRDLY_NAMED_FILE"
|
|
|
|
'
|
|
|
|
|
2016-03-23 10:55:13 +00:00
|
|
|
test_expect_success !MINGW '--show-origin escape special file name characters' '
|
2016-02-19 09:16:02 +00:00
|
|
|
cat >expect <<-\EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
file:"file\" (dq) and spaces.conf" user.custom=true
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
2020-01-24 00:21:03 +00:00
|
|
|
git config --file "$WEIRDLY_NAMED_FILE" --show-origin --list >output &&
|
2016-02-19 09:16:02 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-origin stdin' '
|
|
|
|
cat >expect <<-\EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
standard input: user.custom=true
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
git config --file - --show-origin --list <"$CUSTOM_CONFIG_FILE" >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-origin stdin with file include' '
|
|
|
|
cat >"$INCLUDE_DIR"/stdin.include <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
[user]
|
|
|
|
stdin = include
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
|
|
|
cat >expect <<-EOF &&
|
2020-01-24 00:21:02 +00:00
|
|
|
file:$INCLUDE_DIR/stdin.include include
|
2016-02-19 09:16:02 +00:00
|
|
|
EOF
|
2018-10-05 21:54:03 +00:00
|
|
|
echo "[include]path=\"$INCLUDE_DIR\"/stdin.include" |
|
|
|
|
git config --show-origin --includes --file - user.stdin >output &&
|
|
|
|
|
2016-02-19 09:16:02 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
2020-01-24 00:21:03 +00:00
|
|
|
test_expect_success '--show-origin blob' '
|
2024-01-29 11:07:17 +00:00
|
|
|
test_when_finished "rm -rf repo" &&
|
|
|
|
git init repo &&
|
|
|
|
(
|
|
|
|
cd repo &&
|
|
|
|
blob=$(git hash-object -w "$CUSTOM_CONFIG_FILE") &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
blob:$blob user.custom=true
|
|
|
|
EOF
|
|
|
|
git config --blob=$blob --show-origin --list >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
)
|
2016-02-19 09:16:02 +00:00
|
|
|
'
|
|
|
|
|
2020-01-24 00:21:03 +00:00
|
|
|
test_expect_success '--show-origin blob ref' '
|
2024-01-29 11:07:17 +00:00
|
|
|
test_when_finished "rm -rf repo" &&
|
|
|
|
git init repo &&
|
|
|
|
(
|
|
|
|
cd repo &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
blob:main:custom.conf user.custom=true
|
|
|
|
EOF
|
|
|
|
cp "$CUSTOM_CONFIG_FILE" custom.conf &&
|
|
|
|
git add custom.conf &&
|
|
|
|
git commit -m "new config file" &&
|
|
|
|
git config --blob=main:custom.conf --show-origin --list >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
)
|
2016-02-19 09:16:02 +00:00
|
|
|
'
|
|
|
|
|
config.c: pass ctx with CLI config
Pass config_context when parsing CLI config. To provide the .kvi member,
refactor out kvi_from_param() from the logic that caches CLI config in
configsets. Now that config_context and config_context.kvi is always
present when config machinery calls config callbacks, plumb "kvi" so
that we can remove all calls of current_config_scope() except for
trace2/*.c (which will be handled in a later commit), and remove all
other current_config_*() (the functions themselves and their calls).
Note that this results in .kvi containing a different, more complete
set of information than the mocked up "struct config_source" in
git_config_from_parameters().
Plumbing "kvi" reveals a few places where we've been doing the wrong
thing:
* git_config_parse_parameter() hasn't been setting config source
information, so plumb "kvi" there too.
* Several sites in builtin/config.c have been calling current_config_*()
functions outside of config callbacks (indirectly, via the
format_config() helper), which means they're reading state that isn't
set correctly:
* "git config --get-urlmatch --show-scope" iterates config to collect
values, but then attempts to display the scope after config
iteration, causing the "unknown" scope to be shown instead of the
config file's scope. It's clear that this wasn't intended: we knew
that "--get-urlmatch" couldn't show config source metadata, which is
why "--show-origin" was marked incompatible with "--get-urlmatch"
when it was introduced [1]. It was most likely a mistake that we
allowed "--show-scope" to sneak through.
Fix this by copying the "kvi" value in the collection phase so that
it can be read back later. This means that we can now support "git
config --get-urlmatch --show-origin", but that is left unchanged
for now.
* "git config --default" doesn't have config source metadata when
displaying the default value, so "--show-scope" also results in
"unknown", and "--show-origin" results in a BUG(). Fix this by
treating the default value as if it came from the command line (e.g.
like we do with "git -c" or "git config --file"), using
kvi_from_param().
[1] https://lore.kernel.org/git/20160205112001.GA13397@sigill.intra.peff.net/
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:25 +00:00
|
|
|
test_expect_success '--show-origin with --default' '
|
|
|
|
git config --show-origin --default foo some.key >actual &&
|
|
|
|
echo "command line: foo" >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2020-02-10 00:30:59 +00:00
|
|
|
test_expect_success '--show-scope with --list' '
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
global user.global=true
|
|
|
|
global user.override=global
|
|
|
|
global include.path=$INCLUDE_DIR/absolute.include
|
|
|
|
global user.absolute=include
|
|
|
|
local user.local=true
|
|
|
|
local user.override=local
|
|
|
|
local include.path=../include/relative.include
|
|
|
|
local user.relative=include
|
2022-06-07 21:24:04 +00:00
|
|
|
local core.repositoryformatversion=1
|
|
|
|
local extensions.worktreeconfig=true
|
|
|
|
worktree user.worktree=true
|
2020-02-10 00:30:59 +00:00
|
|
|
command user.cmdline=true
|
|
|
|
EOF
|
2022-06-07 21:24:04 +00:00
|
|
|
git worktree add wt1 &&
|
|
|
|
# We need these to test for worktree scope, but outside of this
|
|
|
|
# test, this is just noise
|
|
|
|
test_config core.repositoryformatversion 1 &&
|
|
|
|
test_config extensions.worktreeConfig true &&
|
|
|
|
git config --worktree user.worktree true &&
|
2020-02-10 00:30:59 +00:00
|
|
|
git -c user.cmdline=true config --list --show-scope >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success !MINGW '--show-scope with --blob' '
|
|
|
|
blob=$(git hash-object -w "$CUSTOM_CONFIG_FILE") &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
command user.custom=true
|
|
|
|
EOF
|
|
|
|
git config --blob=$blob --show-scope --list >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-scope with --local' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
local user.local=true
|
|
|
|
local user.override=local
|
|
|
|
local include.path=../include/relative.include
|
|
|
|
EOF
|
|
|
|
git config --local --list --show-scope >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-scope getting a single value' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
local true
|
|
|
|
EOF
|
|
|
|
git config --show-scope --get user.local >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--show-scope with --show-origin' '
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
global file:$HOME/.gitconfig user.global=true
|
|
|
|
global file:$HOME/.gitconfig user.override=global
|
|
|
|
global file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
|
|
|
|
global file:$INCLUDE_DIR/absolute.include user.absolute=include
|
|
|
|
local file:.git/config user.local=true
|
|
|
|
local file:.git/config user.override=local
|
|
|
|
local file:.git/config include.path=../include/relative.include
|
|
|
|
local file:.git/../include/relative.include user.relative=include
|
|
|
|
command command line: user.cmdline=true
|
|
|
|
EOF
|
|
|
|
git -c user.cmdline=true config --list --show-origin --show-scope >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
config.c: pass ctx with CLI config
Pass config_context when parsing CLI config. To provide the .kvi member,
refactor out kvi_from_param() from the logic that caches CLI config in
configsets. Now that config_context and config_context.kvi is always
present when config machinery calls config callbacks, plumb "kvi" so
that we can remove all calls of current_config_scope() except for
trace2/*.c (which will be handled in a later commit), and remove all
other current_config_*() (the functions themselves and their calls).
Note that this results in .kvi containing a different, more complete
set of information than the mocked up "struct config_source" in
git_config_from_parameters().
Plumbing "kvi" reveals a few places where we've been doing the wrong
thing:
* git_config_parse_parameter() hasn't been setting config source
information, so plumb "kvi" there too.
* Several sites in builtin/config.c have been calling current_config_*()
functions outside of config callbacks (indirectly, via the
format_config() helper), which means they're reading state that isn't
set correctly:
* "git config --get-urlmatch --show-scope" iterates config to collect
values, but then attempts to display the scope after config
iteration, causing the "unknown" scope to be shown instead of the
config file's scope. It's clear that this wasn't intended: we knew
that "--get-urlmatch" couldn't show config source metadata, which is
why "--show-origin" was marked incompatible with "--get-urlmatch"
when it was introduced [1]. It was most likely a mistake that we
allowed "--show-scope" to sneak through.
Fix this by copying the "kvi" value in the collection phase so that
it can be read back later. This means that we can now support "git
config --get-urlmatch --show-origin", but that is left unchanged
for now.
* "git config --default" doesn't have config source metadata when
displaying the default value, so "--show-scope" also results in
"unknown", and "--show-origin" results in a BUG(). Fix this by
treating the default value as if it came from the command line (e.g.
like we do with "git -c" or "git config --file"), using
kvi_from_param().
[1] https://lore.kernel.org/git/20160205112001.GA13397@sigill.intra.peff.net/
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:25 +00:00
|
|
|
test_expect_success '--show-scope with --default' '
|
|
|
|
git config --show-scope --default foo some.key >actual &&
|
|
|
|
echo "command foo" >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
config: allow overriding of global and system configuration
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-04-19 12:31:16 +00:00
|
|
|
test_expect_success 'override global and system config' '
|
config tests: fix harmless but broken "rm -r" cleanup
The "test_when_finished" cleanup phase added in 4179b4897f2 (config:
allow overriding of global and system configuration, 2021-04-19) has
never worked as intended, firstly the ".config/git" is a directory, so
we'd need the "-r" flag, but more importantly the $HOME variable
wasn't properly quoted.
We'd thus end up trying to remove the "trash" part of "trash
directory", which wouldn't fail with "-f", since "rm -f" won't fail on
non-existing files.
It's possible that this would have caused an actual failure if someone
had a $HOME with a space character in it, such that our "rm -f" would
fail to remove an existing directory, but in practice that probably
never happened.
Let's fix both the quoting issue, and the other issue cleanup issue in
4179b4897f2, which is that we were attempting to clean up
~/.config/git, but weren't cleaing up ~/.gitconfig.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-30 10:18:36 +00:00
|
|
|
test_when_finished rm -f \"\$HOME\"/.gitconfig &&
|
config: allow overriding of global and system configuration
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-04-19 12:31:16 +00:00
|
|
|
cat >"$HOME"/.gitconfig <<-EOF &&
|
|
|
|
[home]
|
|
|
|
config = true
|
|
|
|
EOF
|
config tests: fix harmless but broken "rm -r" cleanup
The "test_when_finished" cleanup phase added in 4179b4897f2 (config:
allow overriding of global and system configuration, 2021-04-19) has
never worked as intended, firstly the ".config/git" is a directory, so
we'd need the "-r" flag, but more importantly the $HOME variable
wasn't properly quoted.
We'd thus end up trying to remove the "trash" part of "trash
directory", which wouldn't fail with "-f", since "rm -f" won't fail on
non-existing files.
It's possible that this would have caused an actual failure if someone
had a $HOME with a space character in it, such that our "rm -f" would
fail to remove an existing directory, but in practice that probably
never happened.
Let's fix both the quoting issue, and the other issue cleanup issue in
4179b4897f2, which is that we were attempting to clean up
~/.config/git, but weren't cleaing up ~/.gitconfig.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-30 10:18:36 +00:00
|
|
|
|
|
|
|
test_when_finished rm -rf \"\$HOME\"/.config/git &&
|
config: allow overriding of global and system configuration
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-04-19 12:31:16 +00:00
|
|
|
mkdir -p "$HOME"/.config/git &&
|
|
|
|
cat >"$HOME"/.config/git/config <<-EOF &&
|
|
|
|
[xdg]
|
|
|
|
config = true
|
|
|
|
EOF
|
|
|
|
cat >.git/config <<-EOF &&
|
|
|
|
[local]
|
|
|
|
config = true
|
|
|
|
EOF
|
|
|
|
cat >custom-global-config <<-EOF &&
|
|
|
|
[global]
|
|
|
|
config = true
|
|
|
|
EOF
|
|
|
|
cat >custom-system-config <<-EOF &&
|
|
|
|
[system]
|
|
|
|
config = true
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
global xdg.config=true
|
|
|
|
global home.config=true
|
|
|
|
local local.config=true
|
|
|
|
EOF
|
|
|
|
git config --show-scope --list >output &&
|
|
|
|
test_cmp expect output &&
|
|
|
|
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
system system.config=true
|
|
|
|
global global.config=true
|
|
|
|
local local.config=true
|
|
|
|
EOF
|
2021-04-23 05:47:15 +00:00
|
|
|
GIT_CONFIG_NOSYSTEM=false GIT_CONFIG_SYSTEM=custom-system-config GIT_CONFIG_GLOBAL=custom-global-config \
|
config: allow overriding of global and system configuration
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-04-19 12:31:16 +00:00
|
|
|
git config --show-scope --list >output &&
|
|
|
|
test_cmp expect output &&
|
|
|
|
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
local local.config=true
|
|
|
|
EOF
|
2021-04-23 05:47:15 +00:00
|
|
|
GIT_CONFIG_NOSYSTEM=false GIT_CONFIG_SYSTEM=/dev/null GIT_CONFIG_GLOBAL=/dev/null \
|
|
|
|
git config --show-scope --list >output &&
|
config: allow overriding of global and system configuration
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-04-19 12:31:16 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'override global and system config with missing file' '
|
|
|
|
test_must_fail env GIT_CONFIG_GLOBAL=does-not-exist GIT_CONFIG_SYSTEM=/dev/null git config --global --list &&
|
|
|
|
test_must_fail env GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_SYSTEM=does-not-exist git config --system --list &&
|
|
|
|
GIT_CONFIG_GLOBAL=does-not-exist GIT_CONFIG_SYSTEM=does-not-exist git version
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'system override has no effect with GIT_CONFIG_NOSYSTEM' '
|
|
|
|
# `git config --system` has different semantics compared to other
|
|
|
|
# commands as it ignores GIT_CONFIG_NOSYSTEM. We thus test whether the
|
|
|
|
# variable has an effect via a different proxy.
|
|
|
|
cat >alias-config <<-EOF &&
|
|
|
|
[alias]
|
|
|
|
hello-world = !echo "hello world"
|
|
|
|
EOF
|
|
|
|
test_must_fail env GIT_CONFIG_NOSYSTEM=true GIT_CONFIG_SYSTEM=alias-config \
|
|
|
|
git hello-world &&
|
|
|
|
GIT_CONFIG_NOSYSTEM=false GIT_CONFIG_SYSTEM=alias-config \
|
|
|
|
git hello-world >actual &&
|
|
|
|
echo "hello world" >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'write to overridden global and system config' '
|
|
|
|
cat >expect <<EOF &&
|
|
|
|
[config]
|
|
|
|
key = value
|
|
|
|
EOF
|
|
|
|
|
|
|
|
GIT_CONFIG_GLOBAL=write-to-global git config --global config.key value &&
|
|
|
|
test_cmp expect write-to-global &&
|
|
|
|
|
|
|
|
GIT_CONFIG_SYSTEM=write-to-system git config --system config.key value &&
|
|
|
|
test_cmp expect write-to-system
|
|
|
|
'
|
|
|
|
|
2020-09-09 13:16:08 +00:00
|
|
|
for opt in --local --worktree
|
|
|
|
do
|
|
|
|
test_expect_success "$opt requires a repo" '
|
|
|
|
# we expect 128 to ensure that we do not simply
|
|
|
|
# fail to find anything and return code "1"
|
|
|
|
test_expect_code 128 nongit git config $opt foo.bar
|
|
|
|
'
|
|
|
|
done
|
2017-05-13 03:29:18 +00:00
|
|
|
|
builtin/config.c: treat type specifiers singularly
Internally, we represent `git config`'s type specifiers as a bitset
using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique
allows for the representation of multiple type specifiers in the `int
types` field, but this multi-representation is left unused.
In fact, `git config` will not accept multiple type specifiers at a
time, as indicated by:
$ git config --int --bool some.section
error: only one type at a time.
This patch uses `OPT_SET_INT` to prefer the _last_ mentioned type
specifier, so that the above command would instead be valid, and a
synonym of:
$ git config --bool some.section
This change is motivated by two urges: (1) it does not make sense to
represent a singular type specifier internally as a bitset, only to
complain when there are multiple bits in the set. `OPT_SET_INT` is more
well-suited to this task than `OPT_BIT` is. (2) a future patch will
introduce `--type=<type>`, and we would like not to complain in the
following situation:
$ git config --int --type=int
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 22:46:54 +00:00
|
|
|
cat >.git/config <<-\EOF &&
|
2021-01-03 09:36:48 +00:00
|
|
|
[section]
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
foo = true
|
builtin/config.c: treat type specifiers singularly
Internally, we represent `git config`'s type specifiers as a bitset
using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique
allows for the representation of multiple type specifiers in the `int
types` field, but this multi-representation is left unused.
In fact, `git config` will not accept multiple type specifiers at a
time, as indicated by:
$ git config --int --bool some.section
error: only one type at a time.
This patch uses `OPT_SET_INT` to prefer the _last_ mentioned type
specifier, so that the above command would instead be valid, and a
synonym of:
$ git config --bool some.section
This change is motivated by two urges: (1) it does not make sense to
represent a singular type specifier internally as a bitset, only to
complain when there are multiple bits in the set. `OPT_SET_INT` is more
well-suited to this task than `OPT_BIT` is. (2) a future patch will
introduce `--type=<type>`, and we would like not to complain in the
following situation:
$ git config --int --type=int
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 22:46:54 +00:00
|
|
|
number = 10
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
big = 1M
|
builtin/config.c: treat type specifiers singularly
Internally, we represent `git config`'s type specifiers as a bitset
using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique
allows for the representation of multiple type specifiers in the `int
types` field, but this multi-representation is left unused.
In fact, `git config` will not accept multiple type specifiers at a
time, as indicated by:
$ git config --int --bool some.section
error: only one type at a time.
This patch uses `OPT_SET_INT` to prefer the _last_ mentioned type
specifier, so that the above command would instead be valid, and a
synonym of:
$ git config --bool some.section
This change is motivated by two urges: (1) it does not make sense to
represent a singular type specifier internally as a bitset, only to
complain when there are multiple bits in the set. `OPT_SET_INT` is more
well-suited to this task than `OPT_BIT` is. (2) a future patch will
introduce `--type=<type>`, and we would like not to complain in the
following situation:
$ git config --int --type=int
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 22:46:54 +00:00
|
|
|
EOF
|
|
|
|
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
test_expect_success 'identical modern --type specifiers are allowed' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_cmp_config 1048576 --type=int --type=int section.big
|
builtin/config.c: treat type specifiers singularly
Internally, we represent `git config`'s type specifiers as a bitset
using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique
allows for the representation of multiple type specifiers in the `int
types` field, but this multi-representation is left unused.
In fact, `git config` will not accept multiple type specifiers at a
time, as indicated by:
$ git config --int --bool some.section
error: only one type at a time.
This patch uses `OPT_SET_INT` to prefer the _last_ mentioned type
specifier, so that the above command would instead be valid, and a
synonym of:
$ git config --bool some.section
This change is motivated by two urges: (1) it does not make sense to
represent a singular type specifier internally as a bitset, only to
complain when there are multiple bits in the set. `OPT_SET_INT` is more
well-suited to this task than `OPT_BIT` is. (2) a future patch will
introduce `--type=<type>`, and we would like not to complain in the
following situation:
$ git config --int --type=int
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 22:46:54 +00:00
|
|
|
'
|
|
|
|
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
test_expect_success 'identical legacy --type specifiers are allowed' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_cmp_config 1048576 --int --int section.big
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'identical mixed --type specifiers are allowed' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_cmp_config 1048576 --int --type=int section.big
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'non-identical modern --type specifiers are not allowed' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_must_fail git config --type=int --type=bool section.big 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "only one type at a time" error
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'non-identical legacy --type specifiers are not allowed' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_must_fail git config --int --bool section.big 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "only one type at a time" error
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'non-identical mixed --type specifiers are not allowed' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_must_fail git config --type=int --bool section.big 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "only one type at a time" error
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--type allows valid type specifiers' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_cmp_config true --type=bool section.foo
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--no-type unsets type specifiers' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_cmp_config 10 --type=bool --no-type section.number
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'unset type specifiers may be reset to conflicting ones' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_cmp_config 1048576 --type=bool --no-type --type=int section.big
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--type rejects unknown specifiers' '
|
2021-01-03 09:36:48 +00:00
|
|
|
test_must_fail git config --type=nonsense section.foo 2>error &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "unrecognized --type argument" error
|
builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values can be interpreted as that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to extend this functionality with
`--type=color` and `--default` to replace `--get-color`.
However, we traditionally use `--color` to mean "colorize this output",
instead of "this value should be treated as a color".
Currently, `git config` does not support this kind of colorization, but
we should be careful to avoid squatting on this option too soon, so that
`git config` can support `--color` (in the traditional sense) in the
future, if that is desired.
In this patch, we support `--type=<int|bool|bool-or-int|...>` in
addition to `--int`, `--bool`, and etc. This allows the aforementioned
upcoming patch to support querying a color value with a default via
`--type=color --default=...`, without squandering `--color`.
We retain the historic behavior of complaining when multiple,
legacy-style `--<type>` flags are given, as well as extend this to
conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
commutative pair) does not complain, but `--bool --type=int` (and its
commutative pair) does.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-18 21:43:35 +00:00
|
|
|
'
|
|
|
|
|
2022-11-09 14:16:27 +00:00
|
|
|
test_expect_success '--type=int requires at least one digit' '
|
|
|
|
test_must_fail git config --type int --default m some.key >out 2>error &&
|
|
|
|
grep "bad numeric config value" error &&
|
|
|
|
test_must_be_empty out
|
|
|
|
'
|
|
|
|
|
2018-04-03 16:28:14 +00:00
|
|
|
test_expect_success '--replace-all does not invent newlines' '
|
2018-04-03 16:28:10 +00:00
|
|
|
q_to_tab >.git/config <<-\EOF &&
|
|
|
|
[abc]key
|
|
|
|
QkeepSection
|
|
|
|
[xyz]
|
|
|
|
Qkey = 1
|
|
|
|
[abc]
|
|
|
|
Qkey = a
|
|
|
|
EOF
|
|
|
|
q_to_tab >expect <<-\EOF &&
|
|
|
|
[abc]
|
|
|
|
QkeepSection
|
|
|
|
[xyz]
|
|
|
|
Qkey = 1
|
|
|
|
[abc]
|
|
|
|
Qkey = b
|
|
|
|
EOF
|
|
|
|
git config --replace-all abc.key b &&
|
2018-10-05 21:54:04 +00:00
|
|
|
test_cmp expect .git/config
|
2018-04-03 16:28:10 +00:00
|
|
|
'
|
|
|
|
|
2020-11-25 22:12:51 +00:00
|
|
|
test_expect_success 'set all config with value-pattern' '
|
|
|
|
test_when_finished rm -f config initial &&
|
|
|
|
git config --file=initial abc.key one &&
|
|
|
|
|
|
|
|
# no match => add new entry
|
|
|
|
cp initial config &&
|
|
|
|
git config --file=config abc.key two a+ &&
|
|
|
|
git config --file=config --list >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
abc.key=one
|
|
|
|
abc.key=two
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
# multiple matches => failure
|
|
|
|
test_must_fail git config --file=config abc.key three o+ 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "has multiple values" err &&
|
2020-11-25 22:12:51 +00:00
|
|
|
|
|
|
|
# multiple values, no match => add
|
|
|
|
git config --file=config abc.key three a+ &&
|
|
|
|
git config --file=config --list >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
abc.key=one
|
|
|
|
abc.key=two
|
|
|
|
abc.key=three
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
# single match => replace
|
|
|
|
git config --file=config abc.key four h+ &&
|
|
|
|
git config --file=config --list >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
abc.key=one
|
|
|
|
abc.key=two
|
|
|
|
abc.key=four
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2020-11-25 22:12:52 +00:00
|
|
|
test_expect_success '--replace-all and value-pattern' '
|
|
|
|
test_when_finished rm -f config &&
|
|
|
|
git config --file=config --add abc.key one &&
|
|
|
|
git config --file=config --add abc.key two &&
|
|
|
|
git config --file=config --add abc.key three &&
|
|
|
|
git config --file=config --replace-all abc.key four "o+" &&
|
|
|
|
git config --file=config --list >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
abc.key=four
|
|
|
|
abc.key=three
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2020-11-25 22:12:53 +00:00
|
|
|
test_expect_success 'refuse --fixed-value for incompatible actions' '
|
|
|
|
test_when_finished rm -f config &&
|
|
|
|
git config --file=config dev.null bogus &&
|
|
|
|
|
|
|
|
# These modes do not allow --fixed-value at all
|
|
|
|
test_must_fail git config --file=config --fixed-value --add dev.null bogus &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --get-urlmatch dev.null bogus &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --get-urlmatch dev.null bogus &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --rename-section dev null &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --remove-section dev &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --list &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --get-color dev.null &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --get-colorbool dev.null &&
|
|
|
|
|
|
|
|
# These modes complain when --fixed-value has no value-pattern
|
|
|
|
test_must_fail git config --file=config --fixed-value dev.null bogus &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --replace-all dev.null bogus &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --get dev.null &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --get-all dev.null &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --get-regexp "dev.*" &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --unset dev.null &&
|
|
|
|
test_must_fail git config --file=config --fixed-value --unset-all dev.null
|
|
|
|
'
|
|
|
|
|
2020-11-25 22:12:54 +00:00
|
|
|
test_expect_success '--fixed-value uses exact string matching' '
|
|
|
|
test_when_finished rm -f config initial &&
|
|
|
|
META="a+b*c?d[e]f.g" &&
|
|
|
|
git config --file=initial fixed.test "$META" &&
|
|
|
|
|
|
|
|
cp initial config &&
|
|
|
|
git config --file=config fixed.test bogus "$META" &&
|
|
|
|
git config --file=config --list >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
fixed.test=$META
|
|
|
|
fixed.test=bogus
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
cp initial config &&
|
|
|
|
git config --file=config --fixed-value fixed.test bogus "$META" &&
|
|
|
|
git config --file=config --list >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
fixed.test=bogus
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
cp initial config &&
|
|
|
|
test_must_fail git config --file=config --unset fixed.test "$META" &&
|
|
|
|
git config --file=config --fixed-value --unset fixed.test "$META" &&
|
|
|
|
test_must_fail git config --file=config fixed.test &&
|
|
|
|
|
|
|
|
cp initial config &&
|
|
|
|
test_must_fail git config --file=config --unset-all fixed.test "$META" &&
|
|
|
|
git config --file=config --fixed-value --unset-all fixed.test "$META" &&
|
|
|
|
test_must_fail git config --file=config fixed.test &&
|
|
|
|
|
|
|
|
cp initial config &&
|
|
|
|
git config --file=config --replace-all fixed.test bogus "$META" &&
|
|
|
|
git config --file=config --list >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
fixed.test=$META
|
|
|
|
fixed.test=bogus
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
git config --file=config --fixed-value --replace-all fixed.test bogus "$META" &&
|
|
|
|
git config --file=config --list >actual &&
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
fixed.test=bogus
|
|
|
|
fixed.test=bogus
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2020-11-25 22:12:55 +00:00
|
|
|
test_expect_success '--get and --get-all with --fixed-value' '
|
|
|
|
test_when_finished rm -f config &&
|
|
|
|
META="a+b*c?d[e]f.g" &&
|
|
|
|
git config --file=config fixed.test bogus &&
|
|
|
|
git config --file=config --add fixed.test "$META" &&
|
|
|
|
|
|
|
|
git config --file=config --get fixed.test bogus &&
|
|
|
|
test_must_fail git config --file=config --get fixed.test "$META" &&
|
|
|
|
git config --file=config --get --fixed-value fixed.test "$META" &&
|
|
|
|
test_must_fail git config --file=config --get --fixed-value fixed.test non-existent &&
|
|
|
|
|
|
|
|
git config --file=config --get-all fixed.test bogus &&
|
|
|
|
test_must_fail git config --file=config --get-all fixed.test "$META" &&
|
|
|
|
git config --file=config --get-all --fixed-value fixed.test "$META" &&
|
|
|
|
test_must_fail git config --file=config --get-all --fixed-value fixed.test non-existent &&
|
|
|
|
|
|
|
|
git config --file=config --get-regexp fixed+ bogus &&
|
|
|
|
test_must_fail git config --file=config --get-regexp fixed+ "$META" &&
|
|
|
|
git config --file=config --get-regexp --fixed-value fixed+ "$META" &&
|
|
|
|
test_must_fail git config --file=config --get-regexp --fixed-value fixed+ non-existent
|
|
|
|
'
|
|
|
|
|
2022-01-18 17:47:40 +00:00
|
|
|
test_expect_success 'includeIf.hasconfig:remote.*.url' '
|
|
|
|
git init hasremoteurlTest &&
|
|
|
|
test_when_finished "rm -rf hasremoteurlTest" &&
|
|
|
|
|
|
|
|
cat >include-this <<-\EOF &&
|
|
|
|
[user]
|
|
|
|
this = this-is-included
|
|
|
|
EOF
|
|
|
|
cat >dont-include-that <<-\EOF &&
|
|
|
|
[user]
|
|
|
|
that = that-is-not-included
|
|
|
|
EOF
|
|
|
|
cat >>hasremoteurlTest/.git/config <<-EOF &&
|
|
|
|
[includeIf "hasconfig:remote.*.url:foourl"]
|
|
|
|
path = "$(pwd)/include-this"
|
|
|
|
[includeIf "hasconfig:remote.*.url:barurl"]
|
|
|
|
path = "$(pwd)/dont-include-that"
|
|
|
|
[remote "foo"]
|
|
|
|
url = foourl
|
|
|
|
EOF
|
|
|
|
|
|
|
|
echo this-is-included >expect-this &&
|
|
|
|
git -C hasremoteurlTest config --get user.this >actual-this &&
|
|
|
|
test_cmp expect-this actual-this &&
|
|
|
|
|
|
|
|
test_must_fail git -C hasremoteurlTest config --get user.that
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'includeIf.hasconfig:remote.*.url respects last-config-wins' '
|
|
|
|
git init hasremoteurlTest &&
|
|
|
|
test_when_finished "rm -rf hasremoteurlTest" &&
|
|
|
|
|
|
|
|
cat >include-two-three <<-\EOF &&
|
|
|
|
[user]
|
|
|
|
two = included-config
|
|
|
|
three = included-config
|
|
|
|
EOF
|
|
|
|
cat >>hasremoteurlTest/.git/config <<-EOF &&
|
|
|
|
[remote "foo"]
|
|
|
|
url = foourl
|
|
|
|
[user]
|
|
|
|
one = main-config
|
|
|
|
two = main-config
|
|
|
|
[includeIf "hasconfig:remote.*.url:foourl"]
|
|
|
|
path = "$(pwd)/include-two-three"
|
|
|
|
[user]
|
|
|
|
three = main-config
|
|
|
|
EOF
|
|
|
|
|
|
|
|
echo main-config >expect-main-config &&
|
|
|
|
echo included-config >expect-included-config &&
|
|
|
|
|
|
|
|
git -C hasremoteurlTest config --get user.one >actual &&
|
|
|
|
test_cmp expect-main-config actual &&
|
|
|
|
|
|
|
|
git -C hasremoteurlTest config --get user.two >actual &&
|
|
|
|
test_cmp expect-included-config actual &&
|
|
|
|
|
|
|
|
git -C hasremoteurlTest config --get user.three >actual &&
|
|
|
|
test_cmp expect-main-config actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'includeIf.hasconfig:remote.*.url globs' '
|
|
|
|
git init hasremoteurlTest &&
|
|
|
|
test_when_finished "rm -rf hasremoteurlTest" &&
|
|
|
|
|
|
|
|
printf "[user]\ndss = yes\n" >double-star-start &&
|
|
|
|
printf "[user]\ndse = yes\n" >double-star-end &&
|
|
|
|
printf "[user]\ndsm = yes\n" >double-star-middle &&
|
|
|
|
printf "[user]\nssm = yes\n" >single-star-middle &&
|
|
|
|
printf "[user]\nno = no\n" >no &&
|
|
|
|
|
|
|
|
cat >>hasremoteurlTest/.git/config <<-EOF &&
|
|
|
|
[remote "foo"]
|
|
|
|
url = https://foo/bar/baz
|
|
|
|
[includeIf "hasconfig:remote.*.url:**/baz"]
|
|
|
|
path = "$(pwd)/double-star-start"
|
|
|
|
[includeIf "hasconfig:remote.*.url:**/nomatch"]
|
|
|
|
path = "$(pwd)/no"
|
|
|
|
[includeIf "hasconfig:remote.*.url:https:/**"]
|
|
|
|
path = "$(pwd)/double-star-end"
|
|
|
|
[includeIf "hasconfig:remote.*.url:nomatch:/**"]
|
|
|
|
path = "$(pwd)/no"
|
|
|
|
[includeIf "hasconfig:remote.*.url:https:/**/baz"]
|
|
|
|
path = "$(pwd)/double-star-middle"
|
|
|
|
[includeIf "hasconfig:remote.*.url:https:/**/nomatch"]
|
|
|
|
path = "$(pwd)/no"
|
|
|
|
[includeIf "hasconfig:remote.*.url:https://*/bar/baz"]
|
|
|
|
path = "$(pwd)/single-star-middle"
|
|
|
|
[includeIf "hasconfig:remote.*.url:https://*/baz"]
|
|
|
|
path = "$(pwd)/no"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
git -C hasremoteurlTest config --get user.dss &&
|
|
|
|
git -C hasremoteurlTest config --get user.dse &&
|
|
|
|
git -C hasremoteurlTest config --get user.dsm &&
|
|
|
|
git -C hasremoteurlTest config --get user.ssm &&
|
|
|
|
test_must_fail git -C hasremoteurlTest config --get user.no
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'includeIf.hasconfig:remote.*.url forbids remote url in such included files' '
|
|
|
|
git init hasremoteurlTest &&
|
|
|
|
test_when_finished "rm -rf hasremoteurlTest" &&
|
|
|
|
|
|
|
|
cat >include-with-url <<-\EOF &&
|
|
|
|
[remote "bar"]
|
|
|
|
url = barurl
|
|
|
|
EOF
|
|
|
|
cat >>hasremoteurlTest/.git/config <<-EOF &&
|
|
|
|
[includeIf "hasconfig:remote.*.url:foourl"]
|
|
|
|
path = "$(pwd)/include-with-url"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# test with any Git command
|
|
|
|
test_must_fail git -C hasremoteurlTest status 2>err &&
|
|
|
|
grep "fatal: remote URLs cannot be configured in file directly or indirectly included by includeIf.hasconfig:remote.*.url" err
|
|
|
|
'
|
|
|
|
|
2005-11-17 21:50:08 +00:00
|
|
|
test_done
|