git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).