threads / patch / 10211

patchgit-config: respect other options after -l, most notably --file

Subject: [PATCH] git-config: respect other options after -l, most notably --file

## tl;dr

4 messages between Oct 9, 2007 and Oct 12, 2007. Diffs are folded; open one to read it.

replies: 3people: 3as markdown or json

Gerrit Pape· Oct 9, 2007, 12:50 UTC · lore

When git-commit is seeing the -l|--list option, it stops reading the following command line options. So although they should be the same, the following commands act differently:

 git config --file ../repo2/.git/config -l
 git config -l --file ../repo2/.git/config

This patch delays the 'list all variables' to after the command line options have been processed.

The problem was noticed by Joey Hess, reported through
 http://bugs.debian.org/445208
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
 builtin-config.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)
Show changes to builtin-config.c +4 −1
diff --git a/builtin-config.c b/builtin-config.c
index c2708ba..1bb0ebb 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -8,6 +8,7 @@ static char *key;
 static regex_t *key_regexp;
 static regex_t *regexp;
 static int show_keys;
+static int show_all;
 static int use_key_regexp;
 static int do_all;
 static int do_not_match;
@@ -173,7 +174,7 @@ int cmd_config(int argc, const char **argv, const char *prefix)
 		else if (!strcmp(argv[1], "--bool"))
 			type = T_BOOL;
 		else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
-			return git_config(show_all_config);
+			show_all = 1;
 		else if (!strcmp(argv[1], "--global")) {
 			char *home = getenv("HOME");
 			if (home) {
@@ -234,6 +235,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
 		argv++;
 	}
 
+	if (show_all)
+		return git_config(show_all_config);
 	switch (argc) {
 	case 2:
 		return get_value(argv[1], NULL);
-- 
1.5.3.4
Johannes Schindelin· Oct 9, 2007, 13:15 UTC · re: Gerrit Pape · lore

Re: [PATCH] git-config: respect other options after -l, most notably --file

Hi,
On Tue, 9 Oct 2007, Gerrit Pape wrote:
Show 9 quoted lines
> @@ -234,6 +235,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
>  		argv++;
>  	}
>  
> +	if (show_all)
> +		return git_config(show_all_config);
>  	switch (argc) {
>  	case 2:
>  		return get_value(argv[1], NULL);

Shouldn't this somehow check if argc == 1 when show_all is set, and die otherwise?

Ciao, Dscho

Frank Lichtenheld· Oct 9, 2007, 22:49 UTC · re: Gerrit Pape · lore

Re: [PATCH] git-config: respect other options after -l, most notably --file

On Tue, Oct 09, 2007 at 12:50:24PM +0000, Gerrit Pape wrote:
Show 9 quoted lines
> When git-commit is seeing the -l|--list option, it stops reading the
> following command line options.  So although they should be the same,
> the following commands act differently:
> 
>  git config --file ../repo2/.git/config -l
>  git config -l --file ../repo2/.git/config
> 
> This patch delays the 'list all variables' to after the command line
> options have been processed.

Note that I have posted a conflicting patch for the same problem some days ago. I think my patch is more consistent with the behaviour for other options.

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
Gerrit Pape· Oct 12, 2007, 11:37 UTC · re: Frank Lichtenheld · lore

[PATCH drop] git-config: respect other options after -l, most notably --file

On Wed, Oct 10, 2007 at 12:49:43AM +0200, Frank Lichtenheld wrote:
Show 14 quoted lines
> On Tue, Oct 09, 2007 at 12:50:24PM +0000, Gerrit Pape wrote:
> > When git-commit is seeing the -l|--list option, it stops reading the
> > following command line options.  So although they should be the same,
> > the following commands act differently:
> > 
> >  git config --file ../repo2/.git/config -l
> >  git config -l --file ../repo2/.git/config
> > 
> > This patch delays the 'list all variables' to after the command line
> > options have been processed.
> 
> Note that I have posted a conflicting patch for the same problem some
> days ago. I think my patch is more consistent with the behaviour for
> other options.
Fair enough.  Regards, Gerrit.

← back to recent threads