All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.