[PATCH] config: treat non-existent config files as empty

The git_config() function signals error by returning -1 in
two instances:

  1. An actual error occurs in opening a config file (parse
     errors cause an immediate die).

  2. Of the three possible config files, none was found.

However, this second case is often not an error at all; it
simply means that the user has no configuration (they are
outside a repo, and they have no ~/.gitconfig file). This
can lead to confusing errors, such as when the bash
completion calls "git config --list" outside of a repo. If
the user has a ~/.gitconfig, the command completes
succesfully; if they do not, it complains to stderr.

This patch allows callers of git_config to distinguish
between the two cases. Error is signaled by -1, and
otherwise the return value is the number of files parsed.
This means that the traditional "git_config(...) < 0" check
for error should work, but callers who want to know whether
we parsed any files or not can still do so.

Signed-off-by: Jeff King <redacted>
---
Another cleaned up re-post. Original discussion here:

  http://article.gmane.org/gmane.comp.version-control.git/128206

Your original questions/objections were:

  1. Does it still error on GIT_CONFIG=/nonexistent? I said then I
     hadn't tested. I just did, and it does still produce an error.

  2. You mentioned some other issues in the config code. While I agree
     they could be fixed, they are outside the scope of this patch,
     which does fix something we both agreed was a bug.

The original also had to fix up a callsite for the new semantics, but
that callsite is now gone.

 config.c               |    4 +---
 t/t1300-repo-config.sh |    8 ++++++++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/config.c b/config.c
index 4b0a820..c63d683 100644
--- a/config.c
+++ b/config.c

@@ -871,9 +871,7 @@ int git_config(config_fn_t fn, void *data)
 	if (config_parameters)
 		found += 1;
 
-	if (found == 0)
-		return -1;
-	return ret;
+	return ret == 0 ? found : ret;
 }
 
 /*

diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 074f2f2..6f6ed2d 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh

@@ -289,6 +289,14 @@ test_expect_success 'working --list' \
 	'git config --list > output && cmp output expect'
 
 cat > expect << EOF
+EOF
+
+test_expect_success '--list without repo produces empty output' '
+	git --git-dir=nonexistent config --list >output &&
+	test_cmp expect output
+'
+
+cat > expect << EOF
 beta.noindent sillyValue
 nextsection.nonewline wow2 for me
 EOF

-- 
1.7.3.1.235.gdd6c0

Jeff King wrote:

  1. Does it still error on GIT_CONFIG=/nonexistent? I said then I
     hadn't tested. I just did, and it does still produce an error.

Maybe it would make sense to squash in something like this, then.

Signed-off-by: Jonathan Nieder <redacted>
---

diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index c703257..d0e5546 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh

@@ -844,6 +844,27 @@ test_expect_success SYMLINKS 'symlinked configuration' '
 
 '
 
+test_expect_success 'nonexistent configuration' '
+	(
+		GIT_CONFIG=doesnotexist &&
+		export GIT_CONFIG &&
+		test_must_fail git config --list &&
+		test_must_fail git config test.xyzzy
+	)
+'
+
+test_expect_success SYMLINKS 'symlink to nonexistent configuration' '
+	ln -s doesnotexist linktonada &&
+	ln -s linktonada linktolinktonada &&
+	(
+		GIT_CONFIG=linktonada &&
+		export GIT_CONFIG &&
+		test_must_fail git config --list &&
+		GIT_CONFIG=linktolinktonada &&
+		test_must_fail git config --list
+	)
+'
+
 test_expect_success 'check split_cmdline return' "
 	git config alias.split-cmdline-fix 'echo \"' &&
 	test_must_fail git split-cmdline-fix &&

On Thu, Oct 21, 2010 at 11:47:08AM -0500, Jonathan Nieder wrote:

Jeff King wrote:

quoted

  1. Does it still error on GIT_CONFIG=/nonexistent? I said then I
     hadn't tested. I just did, and it does still produce an error.

Maybe it would make sense to squash in something like this, then.

Yes, I think it's worth adding those tests. Thanks.

-Peff