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? 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html