Re: git config --get-urlmatch does not set exit code 1 when no match is found

From: John Keeping <john@keeping.me.uk>
Date: Feb 28, 2016, 11:52 UTC
Message-ID: <20160228115227.GU1766@serenity.lan>
In-Reply-To: <20160228104557.GT1766@serenity.lan>

On Sun, Feb 28, 2016 at 10:45:57AM +0000, John Keeping wrote:

Show 24 quoted lines

> On Sun, Feb 28, 2016 at 10:09:12AM +0530, Guilherme wrote:
> > My current woes are with multi-valued configuration values. More
> > specifically credential.helper
> > 
> > The documentation of git config says that when a value is not matched
> > it should return 1.
> > 
> > To reproduce make sure that credential.helper is not set.
> > 
> > git config --get-urlmatch credential.helper http://somedomain:1234/
> > echo %ERRORLEVEL%
> > 0
> > 
> > git config --get credential.helper
> > echo %ERRORLEVEL%
> > 1
> > 
> > git config --get credential.http://somedomain:1234/.helper
> > echo %ERRORLEVEL%
> > 1
> > 
> > The documentation says that for credential.helper is not found for a
> > domain it should fall back to credential.helper if it is set. So I
> > think that all those tests above should have returned 0. Am i right?

I misread this as "should have returned 1", which is what the text below agrees with.

The "git config" command does not know anything about the semantics of particular config keys. It is purely an interface to parse and query the config file format and it is up to the consumer to know what to do if a key doesn't exist.

Both of the "git config --get" examples you give are behaving as documented in git-config(1).

Show 28 quoted lines

> It looks to me like a simple bug that --get-urlmatch doesn't return 1 if
> the key isn't found, but git-config(1) isn't entirely clear.  The
> overall documentation on exit codes at the end of DESCRIPTION says that
> exit code 1 means:
> 
> 	the section or key is invalid (ret=1)
> 
> Then the documentation for the --get option says:
> 
> 	Returns error code 1 if the key was not found.
> 
> and --get-all says:
> 
> 	Like get, but does not fail if the number of values for the key
> 	is not exactly one.
> 
> although it does return 1 if there are zero values.  --get-regexp
> behaves in the same way.
> 
> Overall I think that the fact that --get-urlmatch is the outlier here
> means that it should change to match the other --get* options (ignoring
> --get-color and --get-colorbool which are very different).  Although I
> wonder if anyone is relying on the current behaviour and will find their
> workflow broken if we change this.
> 
> The documentation could also use some clarification since most of the
> return codes only apply for the "set" options and in some cases this
> isn't clear from the existing descriptions.