Re: [PATCH v5 2/3] config: add 'type' to config_source struct that identifies config type

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v5 2/3] config: add 'type' to config_source struct that identifies config type

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:08:17

Junio C Hamano [off-list ref] writes:
larsxschneider@gmail.com writes:
quoted
From: Lars Schneider <redacted>

Use the config type to print more detailed error messages that inform
the user about the origin of a config error (file, stdin, blob).
"type" is too broad a word in the context of configuration file, and
does not help readers as a variable or a field name in a structure.
You are not talking about "this is a binary typed variable", for
example.

If showing the origin is useful to the user, that origin should be
called origin, not type, I would think.
You seem to use in 3/3 "origin type", and I think that is a sensible
phrasing.  Renaming 'type' to 'origin' in this patch would not be a
good idea, but renaming it to 'origin_type' would be a great thing
to do.

In the context of configuration parsing, 'origin' would be like
"file called .git/config", "standard input", "command line's 3rd
argument", etc., i.e. for some origin types, it would consist of
<origin_type=file, origin_value=.git/config> pair, while some other
origin type (e.g. "standard input") there is no need for an
"origin_value" that further qualifies the origin.

Thanks.

Re: [PATCH v5 2/3] config: add 'type' to config_source struct that identifies config type

From: Lars Schneider <hidden>
Date: 2016-06-15 23:08:18

On 17 Feb 2016, at 22:31, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
larsxschneider@gmail.com writes:
quoted
From: Lars Schneider <redacted>

Use the config type to print more detailed error messages that inform
the user about the origin of a config error (file, stdin, blob).
"type" is too broad a word in the context of configuration file, and
does not help readers as a variable or a field name in a structure.
You are not talking about "this is a binary typed variable", for
example.

If showing the origin is useful to the user, that origin should be
called origin, not type, I would think.
You seem to use in 3/3 "origin type", and I think that is a sensible
phrasing.  Renaming 'type' to 'origin' in this patch would not be a
good idea, but renaming it to 'origin_type' would be a great thing
to do.
OK, I agree. I will wait one more day for other comments and make a
reroll with the change tomorrow.

Thanks,
Lars

In the context of configuration parsing, 'origin' would be like
"file called .git/config", "standard input", "command line's 3rd
argument", etc., i.e. for some origin types, it would consist of
<origin_type=file, origin_value=.git/config> pair, while some other
origin type (e.g. "standard input") there is no need for an
"origin_value" that further qualifies the origin.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help