Re: [PATCH v2 0/2] clang-format

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 15, 2017, 03:03 UTC
Message-ID: <xmqqmv71sfbc.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170815014704.thmpoz5xteuhqh3d@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

> On Mon, Aug 14, 2017 at 04:15:40PM -0700, Stefan Beller wrote:
>
>> + llvm-dev@lists.llvm.org
>> 
>> The Git community is currently discussing adopting a coding style
>> defined by clang-format, here is a bug report:
>
> Since we've added a cc, let me try to give a little more context.

Thanks for relaying; I've dropped them from CC: for this message, as the remainder is not of interest to them.

Show 12 quoted lines

> I'm tempted to say that "config --list" should normalize this case into:
>
>   mysection.mykey=true
>
> Normally we avoid coercing values without knowing the context in which
> they'll be used. But the syntax in the original file means the user is
> telling us it's a boolean and they expect it to be treated that way.
>
> The only downside is if the user is wrong, it might be coerced into
> the string "true" instead of throwing an error. That seems like a minor
> drawback for eliminating a potentially confusing corner case from the
> plumbing output.

Because we cannot sensibly always normalize a variable set to 'yes', 'on', etc. to all "true", the degree it can help the reading scripts is quite limited, as they need to be prepared to see other representation of the truth values anyway. Even though I too found the approach somewhat tempting, because there is no ambiguity in "[section] var" that it means a boolean "true", I doubt it would help very much.

The way they pass "non_string_options" dict to the loader is quite sensible for that purpose, as it allows the reader to say "I care about this and that variables, and I know I want them interpreted as int (e.g. 1M) and bool (e.g. 'on') and returned in a normalized form".

I do not mind adding "git config --list --autotype" option, though, with which the reading script tells us that it accepts the chance of false conversion, so that

	[my]
		intVal = 2k
		boolVal
                someVal = on
		otherVal = 1
		moreVal = 2
		anotherVal = 0
		no = no

might be listed as

	my.intval=2048
	my.boolval=true
	my.someval=true
	my.otherval=1
	my.moreval=2
	my.anotherval=0
	my.no=false

Disambiguation rules are up to debate; the above illustrates an extreme position that coerses anything that could be taken as an int and a string that can be taken as a bool as such, but it may not help very much if the reader wants to see boolean values.