From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Fri, 05 Feb 2016 11:31:15 GMT
Subject: Re: [PATCH v1] config: add '--sources' option to print the source of a config value
Message-ID: <56B48803.9080909@gmail.com>
In-Reply-To: <20160205112001.GA13397@sigill.intra.peff.net>

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