From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Christian Couder <christian.couder@gmail.com>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
Arjun Sreedharan <arjun024@gmail.com>,
Philip Oakley <philipoakley@iee.org>, Git <git@vger.kernel.org>
Subject: Re: [PATCH] introduce git root
Date: Thu, 4 Dec 2014 16:12:32 -0500 [thread overview]
Message-ID: <20141204211232.GC19953@peff.net> (raw)
In-Reply-To: <xmqqlhmntf02.fsf@gitster.dls.corp.google.com>
On Thu, Dec 04, 2014 at 11:02:37AM -0800, Junio C Hamano wrote:
> > 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".
My issue is only that "git --foo" has other options besides computables.
So you need to name each option in a way that makes it clear it is
reporting a computable and not doing something else.
Take "git --pager" for instance. That would be a natural choice to
replace "git var GIT_PAGER". But shouldn't "--pager" be the opposite of
the existing "--no-pager"?
So instead we probably need some namespace to indicate that it is a
"showing" option. Like "--show-pager". And then for consistency, we
would probably want to move "--exec-path" to "--show-exec-path",
creating a new "--show-" namespace. Or we could call that namespace
"git var". :)
> 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@pobox.com>" does not).
I do not think "git var --exec-path" is a good idea, nor GIT_EXEC_PATH
for the environment-variable confusion you mentioned. I was thinking of
just creating a new namespace, like:
git var exec-path
git var author-ident
and deprecating the 4 existing GIT_* variables.
> 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.
I am also OK with that, if the details turn out to be not too ugly once
somebody starts digging in. I was just anticipating some ugliness in
advance. :) But I am not planning to work on it in the immediate future,
so whoever does can make that call.
-Peff
next prev parent reply other threads:[~2014-12-04 21:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-29 20:00 [PATCH] introduce git root Arjun Sreedharan
2014-11-29 23:08 ` Philip Oakley
2014-11-30 4:35 ` Arjun Sreedharan
2014-11-30 11:58 ` Matthieu Moy
2014-12-01 3:04 ` Junio C Hamano
2014-12-01 4:17 ` Christian Couder
2014-12-01 4:53 ` Junio C Hamano
2014-12-02 7:04 ` Jeff King
2014-12-02 10:05 ` Christian Couder
2014-12-02 17:26 ` Junio C Hamano
2014-12-04 9:22 ` Jeff King
2014-12-04 19:02 ` Junio C Hamano
2014-12-04 20:00 ` Matthieu Moy
2014-12-04 20:19 ` Junio C Hamano
2014-12-04 21:12 ` Jeff King [this message]
2014-12-04 21:30 ` Junio C Hamano
2014-12-05 2:27 ` Christian Couder
2014-12-05 9:27 ` Jeff King
2014-12-07 5:23 ` Christian Couder
2014-12-09 18:17 ` Junio C Hamano
2014-12-10 9:16 ` Christian Couder
2014-12-10 20:10 ` Jeff King
2014-12-10 21:08 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141204211232.GC19953@peff.net \
--to=peff@peff.net \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=arjun024@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=philipoakley@iee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).