Re: [PATCH v2] config: add '--sources' option to print the source of a config value

[Sebastian Schuberth <sschuberth@gmail.com>]

On Wed, Feb 10, 2016 at 4:40 PM, Jeff King <peff@peff.net> wrote:

>> >   file:<filename>\t</value...>
>> >   blob:<blob>\t<value...>
>> >   stdin\t<value...>
>> >   cmd\t<value...>
>> >
>> > with a single delimited slot for the source, which can then be broken
>> > down further if desired.  I can't think of any reason to prefer one over
>> > the other rather than personal preference, though. They can both be
>> > parsed unambiguously.
>>
>> I also would have expected sopme like the latter, except that I'd also
>> expect a colon after "stdin" and "cmd" (or "cmdline", as said above).
>> I.e. the colon should be part of the prefix to mark it as such.
>
> Yeah, I waffled on that. Having a colon means you can definitely parse
> to the first ":" without looking at what the prefix is. But if you don't
> know what the prefix is, I don't know what good that does you. IOW, I'd

IMO that's asking the wrong question. The question should not be "what
good does it do if we add the colons also there", but "what
justification do we have to introduce an inconsistency by not adding
them".

> That's perl, but I think most languages make prefix-parsing like that
> easy. I dunno. I doubt it matters all that much, and we are deep into
> personal preference. There's already plenty to bikeshed on the option
> name :)

I agree the option wording mostly is personal preference. On the other
hand, I find discussions like these often prematurely waved aside as
bikeshedding, just because e.g. Perl can parse the one as good as the
other. But it's not about Perl, it's about humans. IMO Git has
historically made many mistakes by not caring enough about consistency
in docs, command and command line option naming, so I don't see it as
wasted time to discuss about things like this.

-- 
Sebastian Schuberth