Jeff King <peff@xxxxxxxx> writes:
> On Tue, Dec 02, 2014 at 09:26:00AM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@xxxxxxxx> writes:
>>
>> > There is also "git var", which is a catch-all for printing some deduced
>> > environmental defaults. I'd be just as happy to see it go away, though.
>> > Having:
>> >
>> > git --exec-path
>> > git --toplevel
>> > git --author-ident
>> >
>> > all work would make sense to me (I often get confused between "git
>> > --foo" and "git rev-parse --foo" when trying to get the exec-path and
>> > git-dir). And I don't think it's too late to move in this direction.
>> > We'd have to keep the old interfaces around, of course, but it would
>> > immediately improve discoverability and consistency.
>>
>> Yeah, I too think the above makes sense. I forgot about "var", but
>> it should go at the same time we move kitchen-sink options out of
>> "rev-parse". One less command to worry about at the UI level means
>> you do not have to say "if you want to learn about X, ask 'var', if
>> you want to learn about Y, ask 'rev-parse', use 'git' itself for Z".
>
> Christian raised the issue of cluttering the "git --option" namespace,
> and I do agree that's a potential issue.
I am not sure if that is an issue at all. You will need the same
number of options to cover all the necessary "computables" somewhere
anyway.
"git --show-this-or-that-computable" is not more or not less
cluttering compared to "git var --show-this-or-that-computable".
If we were to move to "git var", which takes "variables" of these
forms:
GIT_AUTHOR_IDENT
GIT_COMMITTER_IDENT
GIT_EDITOR
GIT_PAGER
then scripts that currently use "git --exec-path" need to be
encouraged to instead use "git var GIT_EXEC_PATH". If we have so
many computables that "cluttering" may become an issue, then we
would need to come up with many new GIT_$COMPUTABLE_NAME fake
variables for consistency if we were to go with "git var", no?
I understand we are not talking about removing "git --exec-path",
but the desire is to have one single command the user can go to ask
about all the computables. If "var" is to become that single
command, then we need to keep the interface to it uniform and
consistent, and telling the users to use "git var GIT_PAGER" and
"git var --exec-path" in the same script will not fly well. Also
these GIT_$COMPUTABLE_NAME appear as if they can be influenced by
setting environment variables of the same name, which invites
further confusion. This is especially bad because some of then do
get affected by environment (i.e. GIT_EDITOR="vi" has effect, but
GIT_AUTHOR_IDENT="Gitster <gitster@xxxxxxxxx>" does not).
> ... My proposal was to drop "git
> var", but I'd also be OK with making "git var" the new kitchen sink. It
> doesn't accept many options now, so it's fairly wide open for changing
> without losing backwards compatibility. AFAICT, the "-l" option is
> utterly useless, but other than that, it just takes a variable name. We
> could introduce dashed options, or just define a sane variable namespace.
If we admit that "git var" was a failed experiment that gained only
four fake variables for the past 10 years, it will not be too much
trouble and transition pain to turn the existing ones into option
form, like --author-ident etc., like your original proposal did, I
would think.
If we are going to deprecate "git var GIT_AUTHOR_IDENT" form,
i.e. the form that uses fake variable-looking strings, and uniformly
use "git var --author-ident", "git var --exec-path", etc., then I
would think it would work, too. I still do not know what you gain
by using "git var --exec-path" over "git --exec-path", though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html