I was hoping to write something like this:
[user]
name = Luser
email = some-default@example.com
[include]
path = ~/.gitconfig.d/user-email
Where that file would contain:
[user]
email = local-email@example.com
But when you do that git prints:
$ git config --get user.email
some-default@example.com
error: More than one value for the key user.email: local-email@example.com
I couldn't find information in either the commt that introduced the
feature or the documentation explaining whether this was the intent or
not.
I think config inclusion is much less useful when you can't clobber
previously assigned values.
From: Jeff King <hidden> Date: 2016-06-15 22:55:05
On Mon, Oct 22, 2012 at 05:55:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
I was hoping to write something like this:
[user]
name = Luser
email = some-default@example.com
[include]
path = ~/.gitconfig.d/user-email
Where that file would contain:
[user]
email = local-email@example.com
The intent is that it would work as you expect, and produce
local-email@example.com.
But when you do that git prints:
$ git config --get user.email
some-default@example.com
error: More than one value for the key user.email: local-email@example.com
Ugh. The config code just feeds all the values sequentially to the
callback. The normal callbacks within git will overwrite old values,
whether from earlier in the file, from a file with lower priority (e.g.,
/etc/gitconfig versus ~/.gitconfig), or from an earlier included. Which
you can check with:
$ git var GIT_AUTHOR_IDENT
Luser [off-list ref] 1350936694 -0400
But git-config takes it upon itself to detect duplicates in its
callback. Which is just silly, since it is not something that regular
git would do. git-config should behave as much like the internal git
parser as possible.
I think config inclusion is much less useful when you can't clobber
previously assigned values.
Agreed. But I think the bug is in git-config, not in the include
mechanism. I think I'd like to do something like the patch below, which
just reuses the regular config code for git-config, collects the values,
and then reports them. It does mean we use a little more memory (for the
sake of simplicity, we store values instead of streaming them out), but
the code is much shorter, less confusing, and automatically matches what
regular git_config() does.
It fails a few tests in t1300, but it looks like those tests are testing
for the behavior we have identified as wrong, and should be fixed.
---
builtin/config.c | 111 ++++++++++++-----------------------
1 file changed, 38 insertions(+), 73 deletions(-)
@@ -153,16 +162,12 @@ static int show_config(const char *key_, const char *value_, void *cb)vptr="";must_print_delim=0;}-seen++;-if(dup_error){-error("More than one value for the key %s: %s",-key_,vptr);-}-else{-if(must_print_delim)-printf("%c",key_delim);-printf("%s%c",vptr,term);-}++if(must_print_delim)+strbuf_addch(buf,key_delim);+strbuf_addstr(buf,vptr);+strbuf_addch(buf,term);+if(must_free_vptr)/* If vptr must be freed, it's a pointer to a*dynamicallyallocatedbuffer,it'ssafetocastto
On Mon, Oct 22, 2012 at 11:15 PM, Jeff King [off-list ref] wrote:
On Mon, Oct 22, 2012 at 05:55:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
quoted
I was hoping to write something like this:
[user]
name = Luser
email = some-default@example.com
[include]
path = ~/.gitconfig.d/user-email
Where that file would contain:
[user]
email = local-email@example.com
The intent is that it would work as you expect, and produce
local-email@example.com.
quoted
But when you do that git prints:
$ git config --get user.email
some-default@example.com
error: More than one value for the key user.email: local-email@example.com
Ugh. The config code just feeds all the values sequentially to the
callback. The normal callbacks within git will overwrite old values,
whether from earlier in the file, from a file with lower priority (e.g.,
/etc/gitconfig versus ~/.gitconfig), or from an earlier included. Which
you can check with:
$ git var GIT_AUTHOR_IDENT
Luser [off-list ref] 1350936694 -0400
But git-config takes it upon itself to detect duplicates in its
callback. Which is just silly, since it is not something that regular
git would do. git-config should behave as much like the internal git
parser as possible.
quoted
I think config inclusion is much less useful when you can't clobber
previously assigned values.
Agreed. But I think the bug is in git-config, not in the include
mechanism. I think I'd like to do something like the patch below, which
just reuses the regular config code for git-config, collects the values,
and then reports them. It does mean we use a little more memory (for the
sake of simplicity, we store values instead of streaming them out), but
the code is much shorter, less confusing, and automatically matches what
regular git_config() does.
It fails a few tests in t1300, but it looks like those tests are testing
for the behavior we have identified as wrong, and should be fixed.
I think this patch looks good.
One other thing I think is worth clarifying (and I think should be
broken) is if you write a configuration like:
[foo]
bar = one
[foo]
bar = two
[foo]
bar = three
"git-{config,var} -l" will both give you:
foo.bar=one
foo.bar=two
foo.bar=three
And git config --get foo.bar will give you:
$ git config -f /tmp/test --get foo.bar
one
error: More than one value for the key foo.bar: two
error: More than one value for the key foo.bar: three
I think that it would be better if the config mechanism just silently
overwrote keys that clobbered earlier keys like your patch does.
But in addition can we simplify things for the consumers of
"git-{config,var} -l" by only printing:
foo.bar=three
Or are there too many variables like "include.path" that can
legitimately appear more than once.
From: Jeff King <hidden> Date: 2016-06-15 22:55:05
On Tue, Oct 23, 2012 at 04:13:44PM +0200, Ævar Arnfjörð Bjarmason wrote:
quoted
It fails a few tests in t1300, but it looks like those tests are testing
for the behavior we have identified as wrong, and should be fixed.
I think this patch looks good.
Thanks. It had a few minor flaws (like a memory leak). I fixed those,
updated the tests, and split it out into a few more readable commits. In
the process, I managed to uncover and fix a few other memory leaks in
the area. I think this version is much more readable, and writing the
rationale for patch 7 convinced me that it's the right thing to do.
Another round of review would be appreciated.
[1/8]: t1300: style updates
[2/8]: t1300: remove redundant test
[3/8]: t1300: test "git config --get-all" more thoroughly
[4/8]: git-config: remove memory leak of key regexp
[5/8]: git-config: fix regexp memory leaks on error conditions
[6/8]: git-config: collect values instead of immediately printing
[7/8]: git-config: do not complain about duplicate entries
[8/8]: git-config: use git_config_with_options
For those just joining us, the interesting bit is patch 7, which fixes
some inconsistencies between the "git-config" tool and how the internal
config callbacks work.
One other thing I think is worth clarifying (and I think should be
broken) is if you write a configuration like:
[foo]
bar = one
[foo]
bar = two
[foo]
bar = three
"git-{config,var} -l" will both give you:
foo.bar=one
foo.bar=two
foo.bar=three
Yes, that looks right.
And git config --get foo.bar will give you:
$ git config -f /tmp/test --get foo.bar
one
error: More than one value for the key foo.bar: two
error: More than one value for the key foo.bar: three
I think that it would be better if the config mechanism just silently
overwrote keys that clobbered earlier keys like your patch does.
Right.
But in addition can we simplify things for the consumers of
"git-{config,var} -l" by only printing:
foo.bar=three
Or are there too many variables like "include.path" that can
legitimately appear more than once.
No. Some variables can legitimately appear multiple times. E.g.,
remote.*.fetch, remote.*.push, and remote.*.url. Probably more that I am
forgetting. There are not many, but they do exist.
It's OK to tweak the regular "get" for them, since they are already
broken for that case[1]. You need to use "--get-all" if you expect the
variable to have multiple values. But when we are listing, we do not
have the hint as to what is expected, and we need to show all entries.
-Peff
[1] So the one useful thing that the current duplicate check is doing is
flagging errors where you wanted to use --get-all, but forgot to.
However, it's not really a sufficient safeguard anyway, since it
would not catch cases where the list was split across multiple
files (which does work with the internal callbacks that handle
lists, since they never even see that multiple files are involved).
It's much more important for git-config to be consistent with the
internal parsing behavior.
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
The t1300 test script is quite old, and does not use our
modern techniques or styles. This patch updates it in the
following ways:
1. Use test_cmp instead of cmp (to make failures easier to
debug).
2. Use test_cmp instead of 'test $(command) = expected'.
This makes failures much easier to debug, and also
makes sure that $(command) exits appropriately.
3. Write tests with the usual style of:
test_expect_success 'test name' '
test commands &&
...
'
rather than one-liners, or using backslash-continuation.
This is purely a style fixup.
There are still a few command happening outside of
test_expect invocations, but they are all innoccuous system
commands like "cat" and "cp". In an ideal world, each test
would be self sufficient and all commands would happen
inside test_expect, but it is not immediately obvious how
the grouping should work (some of the commands impact the
subsequent tests, and some of them are setting up and
modifying state that many tests depend on). This patch just
picks the low-hanging style fruit, and we can do more fixes
on top later.
Signed-off-by: Jeff King <redacted>
---
t/t1300-repo-config.sh | 185 ++++++++++++++++++++++++++++++-------------------
1 file changed, 113 insertions(+), 72 deletions(-)
@@ -353,41 +374,47 @@ echo false > expectvariable= EOF-test_expect_success'get variable with no value'\-'git config --get novalue.variable ^$'+test_expect_success'get variable with no value''+gitconfig--getnovalue.variable^$+'-test_expect_success'get variable with empty value'\-'git config --get emptyvalue.variable ^$'+test_expect_success'get variable with empty value''+gitconfig--getemptyvalue.variable^$+'echonovalue.variable>expect-test_expect_success'get-regexp variable with no value'\-'gitconfig--get-regexpnovalue>output&&-cmpoutputexpect'+test_expect_success'get-regexp variable with no value''+gitconfig--get-regexpnovalue>output&&+test_cmpexpectoutput'echo'novalue.variable true'>expect-test_expect_success'get-regexp --bool variable with no value'\-'gitconfig--bool--get-regexpnovalue>output&&-cmpoutputexpect'+test_expect_success'get-regexp --bool variable with no value''+gitconfig--bool--get-regexpnovalue>output&&+test_cmpexpectoutput+'echo'emptyvalue.variable '>expect-test_expect_success'get-regexp variable with empty value'\-'gitconfig--get-regexpemptyvalue>output&&-cmpoutputexpect'+test_expect_success'get-regexp variable with empty value''+gitconfig--get-regexpemptyvalue>output&&+test_cmpexpectoutput+'echotrue>expect-test_expect_success'get bool variable with no value'\-'gitconfig--boolnovalue.variable>output&&-cmpoutputexpect'+test_expect_success'get bool variable with no value''+gitconfig--boolnovalue.variable>output&&+test_cmpexpectoutput+'echofalse>expect-test_expect_success'get bool variable with empty value'\-'gitconfig--boolemptyvalue.variable>output&&-cmpoutputexpect'+test_expect_success'get bool variable with empty value''+gitconfig--boolemptyvalue.variable>output&&+test_cmpexpectoutput+' test_expect_success'no arguments, but no crash''test_must_failgitconfig>output2>&1&&
@@ -427,8 +454,9 @@ test_expect_success 'new variable inserts into proper section' 'test_cmpexpect.git/config'-test_expect_success'alternative GIT_CONFIG (non-existing file should fail)'\-'test_must_fail git config --file non-existing-config -l'+test_expect_success'alternative GIT_CONFIG (non-existing file should fail)''+test_must_failgitconfig--filenon-existing-config-l+' cat>other-config<<EOF[ein]
@@ -526,14 +562,17 @@ EOF weird EOF-test_expect_success"rename succeeded""test_cmp expect .git/config"+test_expect_success'rename succeeded''+test_cmpexpect.git/config+' cat>>.git/config<<EOF[branch"vier"]z=1 EOF-test_expect_success"rename a section with a var on the same line"\-'git config --rename-section branch.vier branch.zwei'+test_expect_success'rename a section with a var on the same line''+gitconfig--rename-sectionbranch.vierbranch.zwei+' cat>expect<<EOF# Hallo
@@ -548,7 +587,9 @@ EOFz=1 EOF-test_expect_success"rename succeeded""test_cmp expect .git/config"+test_expect_success'rename succeeded''+test_cmpexpect.git/config+' test_expect_success'renaming empty section name is rejected''test_must_failgitconfig--rename-sectionbranch.zwei""
@@ -844,7 +885,7 @@ test_expect_success 'value continued on next line' ' test_expect_success'value continued on next line''gitconfig--list>result&&-cmpresultexpect+test_cmpresultexpect' cat>.git/config<<\EOF
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
This test checks that git-config fails for an ambiguous
"get", but we check the exact same thing 3 tests beforehand.
Signed-off-by: Jeff King <redacted>
---
I update the matching test later in the series, and I didn't want to
have to do it twice.
t/t1300-repo-config.sh | 4 ----
1 file changed, 4 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
We check that we can "--get-all" a multi-valued variable,
but we do not actually confirm that the output is sensible.
Doing so reveals that it works fine, but this will help us
ensure we do not have regressions in the next few patches,
which will touch this area.
Signed-off-by: Jeff King <redacted>
---
t/t1300-repo-config.sh | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
This is only called once per invocation, so it's not a major
leak, but it's easy to fix.
Signed-off-by: Jeff King <redacted>
---
builtin/config.c | 4 ++++
1 file changed, 4 insertions(+)
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
The get_value function has a goto label for cleaning up on
errors, but it only cleans up half of what the function
might allocate. Let's also clean up the key and regexp
variables there.
Note that we need to take special care when compiling the
regex fails to clean it up ourselves, since it is in a
half-constructed state (we would want to free it, but not
regfree it).
Similarly, we fix git_config_parse_key to return NULL when it
fails, not a pointer to some already-freed memory.
Signed-off-by: Jeff King <redacted>
---
The diff is annoying in an interesting way: what I actually did was move
the regex cleanup code down, but it shows it as moving the bottom bits
up. I think it is just one of those ambiguous cases where either way is
equally valid and minimal.
builtin/config.c | 23 +++++++++++++----------
config.c | 1 +
2 files changed, 14 insertions(+), 10 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
This is a refactor that will allow us to more easily tweak
the behavior for multi-valued variables, and it will
ultimately allow us to remove a lot git-config's custom code
in favor of the regular git_config code.
It does mean we're no longer streaming, and we're storing
more in memory for the --get-all case, but in practice it is
a tiny amount of data, and the results are instantaneous.
Signed-off-by: Jeff King <redacted>
---
The increase in line count is nicely offset by the next two patches.
builtin/config.c | 50 +++++++++++++++++++++++++++++++++++---------------
1 file changed, 35 insertions(+), 15 deletions(-)
@@ -138,15 +149,15 @@ static int show_config(const char *key_, const char *value_, void *cb)vptr="";must_print_delim=0;}-seen++;if(dup_error){error("More than one value for the key %s: %s",key_,vptr);}else{if(must_print_delim)-printf("%c",key_delim);-printf("%s%c",vptr,term);+strbuf_addch(buf,key_delim);+strbuf_addstr(buf,vptr);+strbuf_addch(buf,term);}if(must_free_vptr)/* If vptr must be freed, it's a pointer to a
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
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 [off-list ref] ...
[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 <redacted>
---
builtin/config.c | 27 +++++++++------------------
t/t1300-repo-config.sh | 6 ++++--
t/t9700/test.pl | 3 +--
3 files changed, 14 insertions(+), 22 deletions(-)
@@ -149,16 +146,12 @@ static int collect_config(const char *key_, const char *value_, void *cb)vptr="";must_print_delim=0;}-if(dup_error){-error("More than one value for the key %s: %s",-key_,vptr);-}-else{-if(must_print_delim)-strbuf_addch(buf,key_delim);-strbuf_addstr(buf,vptr);-strbuf_addch(buf,term);-}++if(must_print_delim)+strbuf_addch(buf,key_delim);+strbuf_addstr(buf,vptr);+strbuf_addch(buf,term);+if(must_free_vptr)/* If vptr must be freed, it's a pointer to a*dynamicallyallocatedbuffer,it'ssafetocastto
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
The git-config command has always implemented its own file
lookup and parsing order. This was necessary because its
duplicate-entry handling did not match the way git's
internal callbacks worked. Now that this is no longer the
case, we are free to reuse the existing parsing code.
This saves us a few lines of code, but most importantly, it
means that the logic for which files are examined is
contained only in one place and cannot diverge.
Signed-off-by: Jeff King <redacted>
---
builtin/config.c | 44 ++------------------------------------------
1 file changed, 2 insertions(+), 42 deletions(-)
From: John Szakmeister <hidden> Date: 2016-06-15 22:55:06
On Tue, Oct 23, 2012 at 10:13 AM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
[snip]
And git config --get foo.bar will give you:
$ git config -f /tmp/test --get foo.bar
one
error: More than one value for the key foo.bar: two
error: More than one value for the key foo.bar: three
I think that it would be better if the config mechanism just silently
overwrote keys that clobbered earlier keys like your patch does.
But in addition can we simplify things for the consumers of
"git-{config,var} -l" by only printing:
foo.bar=three
Or are there too many variables like "include.path" that can
legitimately appear more than once.
I frequently use pushurl in my remotes to push my master branch both
to the original repo and my forked version. I find it very helpful in
my workflow, and would hate to lose that. That said, I do like the
idea of having a config file and the ability to override some of the
variables.
-John
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
On Tue, Oct 23, 2012 at 08:46:47PM -0400, John Szakmeister wrote:
On Tue, Oct 23, 2012 at 10:13 AM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
[snip]
quoted
And git config --get foo.bar will give you:
$ git config -f /tmp/test --get foo.bar
one
error: More than one value for the key foo.bar: two
error: More than one value for the key foo.bar: three
I think that it would be better if the config mechanism just silently
overwrote keys that clobbered earlier keys like your patch does.
But in addition can we simplify things for the consumers of
"git-{config,var} -l" by only printing:
foo.bar=three
Or are there too many variables like "include.path" that can
legitimately appear more than once.
I frequently use pushurl in my remotes to push my master branch both
to the original repo and my forked version. I find it very helpful in
my workflow, and would hate to lose that. That said, I do like the
idea of having a config file and the ability to override some of the
variables.
No, that won't go anywhere. We really do have two classes of variables:
things that are expected to be single values, and things that are
expected to be lists.
From the perspective of the config code, we don't know or care which is
which, and just feed all entries sequentially to a C callback. In
practice, the callbacks do one of two things:
1. Append the values into a list.
2. Overwrite, and end up with the final value seen.
The trouble is that git-config has to print the values in a reasonable
way, so it asks the caller to give a hint about which it wants (--get
versus --get-all). But in the single-value case did not behave like the
C callbacks, which is what my series fixes.
Using "git config -l" is more like asking the config machinery to just
feed us everything, which is what the C callbacks see. Which is more
flexible, but way less convenient for the caller. But it doesn't need to
be fixed, since the caller has all the information to implement whatever
semantics they like.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:55:06
On Wed, Oct 24, 2012 at 02:37:12AM -0400, Jeff King wrote:
quoted
Here's a case you forgot to update to test_cmp.
[...]
quoted
And while you are here, you might want to remove this extra space. ;)
Otherwise, looks fine.
Thanks, I'll fix up both.
Here's an updated version of patch 1 that I'm planning on queuing. It's
rather tedious to read, but if anybody feels like giving it one more
run-through, let me know if you see any problems.
I won't bother re-posting the other patches, as they are unchanged on
top.
-- >8 --
Subject: [PATCH] t1300: style updates
The t1300 test script is quite old, and does not use our
modern techniques or styles. This patch updates it in the
following ways:
1. Use test_cmp instead of cmp (to make failures easier to
debug).
2. Use test_cmp instead of 'test $(command) = expected'.
This makes failures much easier to debug, and also
makes sure that $(command) exits appropriately.
3. Use test_must_fail (easier to read, and checks more
rigorously for signal death).
4. Write tests with the usual style of:
test_expect_success 'test name' '
test commands &&
...
'
rather than one-liners, or using backslash-continuation.
This is purely a style fixup.
There are still a few command happening outside of
test_expect invocations, but they are all innoccuous system
commands like "cat" and "cp". In an ideal world, each test
would be self sufficient and all commands would happen
inside test_expect, but it is not immediately obvious how
the grouping should work (some of the commands impact the
subsequent tests, and some of them are setting up and
modifying state that many tests depend on). This patch just
picks the low-hanging style fruit, and we can do more fixes
on top later.
Signed-off-by: Jeff King <redacted>
---
t/t1300-repo-config.sh | 301 +++++++++++++++++++++++++++++--------------------
1 file changed, 178 insertions(+), 123 deletions(-)
@@ -353,41 +377,48 @@ echo false > expectvariable= EOF-test_expect_success'get variable with no value'\-'git config --get novalue.variable ^$'+test_expect_success'get variable with no value''+gitconfig--getnovalue.variable^$+'-test_expect_success'get variable with empty value'\-'git config --get emptyvalue.variable ^$'+test_expect_success'get variable with empty value''+gitconfig--getemptyvalue.variable^$+'echonovalue.variable>expect-test_expect_success'get-regexp variable with no value'\-'gitconfig--get-regexpnovalue>output&&-cmpoutputexpect'+test_expect_success'get-regexp variable with no value''+gitconfig--get-regexpnovalue>output&&+test_cmpexpectoutput+'echo'novalue.variable true'>expect-test_expect_success'get-regexp --bool variable with no value'\-'gitconfig--bool--get-regexpnovalue>output&&-cmpoutputexpect'+test_expect_success'get-regexp --bool variable with no value''+gitconfig--bool--get-regexpnovalue>output&&+test_cmpexpectoutput+'echo'emptyvalue.variable '>expect-test_expect_success'get-regexp variable with empty value'\-'gitconfig--get-regexpemptyvalue>output&&-cmpoutputexpect'+test_expect_success'get-regexp variable with empty value''+gitconfig--get-regexpemptyvalue>output&&+test_cmpexpectoutput+'echotrue>expect-test_expect_success'get bool variable with no value'\-'gitconfig--boolnovalue.variable>output&&-cmpoutputexpect'+test_expect_success'get bool variable with no value''+gitconfig--boolnovalue.variable>output&&+test_cmpexpectoutput+'echofalse>expect-test_expect_success'get bool variable with empty value'\-'gitconfig--boolemptyvalue.variable>output&&-cmpoutputexpect'+test_expect_success'get bool variable with empty value''+gitconfig--boolemptyvalue.variable>output&&+test_cmpexpectoutput+' test_expect_success'no arguments, but no crash''test_must_failgitconfig>output2>&1&&
@@ -427,8 +458,9 @@ test_expect_success 'new variable inserts into proper section' 'test_cmpexpect.git/config'-test_expect_success'alternative GIT_CONFIG (non-existing file should fail)'\-'test_must_fail git config --file non-existing-config -l'+test_expect_success'alternative GIT_CONFIG (non-existing file should fail)''+test_must_failgitconfig--filenon-existing-config-l+' cat>other-config<<EOF[ein]
@@ -526,14 +566,17 @@ EOF weird EOF-test_expect_success"rename succeeded""test_cmp expect .git/config"+test_expect_success'rename succeeded''+test_cmpexpect.git/config+' cat>>.git/config<<EOF[branch"vier"]z=1 EOF-test_expect_success"rename a section with a var on the same line"\-'git config --rename-section branch.vier branch.zwei'+test_expect_success'rename a section with a var on the same line''+gitconfig--rename-sectionbranch.vierbranch.zwei+' cat>expect<<EOF# Hallo
@@ -548,7 +591,9 @@ EOFz=1 EOF-test_expect_success"rename succeeded""test_cmp expect .git/config"+test_expect_success'rename succeeded''+test_cmpexpect.git/config+' test_expect_success'renaming empty section name is rejected''test_must_failgitconfig--rename-sectionbranch.zwei""
@@ -844,7 +884,7 @@ test_expect_success 'value continued on next line' ' test_expect_success'value continued on next line''gitconfig--list>result&&-cmpresultexpect+test_cmpresultexpect' cat>.git/config<<\EOF