On 2/5/2016 12:20, Jeff King wrote:
Hmm. I had originally envisioned this only being used with "--list", but
I guess it makes sense to say "--sources --get" to show where the value
for a particular option is coming from.
Being able to use "--sources --get" is a feature that I'd definitely
like to see, too.
I'm not sure returning here is the best idea. We won't have a config
filename if we are reading from "-c", but if we return early from this
function, it parses differently than every other line. E.g., with your
patch, if I do:
git config -c foo.bar=true config --sources --list
I'll get:
/home/peff/.gitconfig <tab> user.name=Jeff King
/home/peff/.gitconfig <tab> user.email=p...@peff.net
...etc...
foo.bar=true
If somebody is parsing this as a tab-delimited list, then instead of the
source field for that line being empty, it is missing (and it looks like
"foo.bar=true" is the source file). I think it would be more friendly to
consumers of the output to have a blank (i.e., set "fn" to the empty
string and continue in the function).
Or to come up with a special string to denote config values specified on
the command line. Maybe somehting like
<command line> <tab> foo.bar=true
I acknowledge that "<command line>" would be a valid filename on some
filesystems, but I think the risk is rather low that someone would
actually be using that name for a Git config file.
Regards,
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
