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=peff@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