git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Jeff King <peff@peff.net>, Git Mailing List <git@vger.kernel.org>
Subject: Re: Add configuration options for some commonly used command-line options
Date: Mon, 20 Mar 2017 17:56:09 +0700	[thread overview]
Message-ID: <CACsJy8CQzo9K8N3xH_HJq=NjJVOUG9wawC4Mg+UuyFRZCPBpFw@mail.gmail.com> (raw)
In-Reply-To: <CACBZZX4FksU6NujPZ_3GZ45EQ+KdJj5G2sajtRipE1wbaA3URA@mail.gmail.com>

On Sun, Mar 19, 2017 at 8:43 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Sun, Mar 19, 2017 at 2:18 PM, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>> On Sun, Mar 19, 2017 at 11:15:33AM +0100, Matthieu Moy wrote:
>>> I think the main problem is indeed "stop the users from shooting
>>> themselves in the foot". Many command-line options change the behavior
>>> completely so allowing users to enable them by default means allowing
>>> the users to change Git in such a way that scripts calling it are
>>> broken.
>>>
>>> This also doesn't help when troublshouting an issue as these options are
>>> typically something set once and for all and which you forget about.
>>> This typically leads to discussion in Q&A forums like:
>>>
>>> A: Can you run "git foo"?
>>> B: Here's the result: ...
>>> A: I don't understand, I can't reproduce here.
>>>
>>> just because B has a CLI option enabled by default.
>>>
>>> This is the same reasoning that leads Git to forbid aliasing an existing
>>> command to something else.
>>>
>>> OTOH, we already have almost "enable such or such option by default"
>>> with aliases. People who always run "git am" with "-3" can write
>>>
>>> [alias]
>>>         a3 = am -3
>>>
>>> and just run "git a3".
>
> I can't find the E-Mail chain now but this has been discussed on-list
> a while ago. I.e. having some getopt support to say for the push
> command, that the --rebase option can also come from the config, i.e.
> in this case the pull.rebase option.
>
> IIRC the consensus was that such a facility would allow commands or
> individual options to say "this command/option is configurable", thus
> of course all plumbing utilities would be unconfigurable, but
> porcelain scripts would be configurable by default, with some
> exceptions.

This is exactly it! It's much better than adding individual config
variables (less work for sure, but messier). Maybe we should promote
the microproject "Add configuration options for commonly used cmdline
options" to project. If it's too short (I'm guessing the core code
could be done in a month), the gsoc student can always convert more
config to the new way.
-- 
Duy

  reply	other threads:[~2017-03-20 11:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-19  9:57 Add configuration options for some commonly used command-line options (Was: [RFH] GSoC 2015 application) Duy Nguyen
2017-03-19 10:15 ` Add configuration options for some commonly used command-line options Matthieu Moy
2017-03-19 13:18   ` brian m. carlson
2017-03-19 13:43     ` Ævar Arnfjörð Bjarmason
2017-03-20 10:56       ` Duy Nguyen [this message]
2017-03-20 17:32         ` Brandon Williams
2017-03-20 18:18           ` Jeff King
2017-03-31 19:44             ` Brandon McCaig
2017-03-20 18:56           ` Junio C Hamano
2017-03-20 19:14             ` Jeff King
2017-03-20 21:57             ` Ævar Arnfjörð Bjarmason
2017-03-24 23:10       ` [PATCH/RFC] parse-options: add facility to make options configurable Ævar Arnfjörð Bjarmason
2017-03-25 16:47         ` Ævar Arnfjörð Bjarmason
2017-03-25 21:31           ` Jeff King
2017-03-25 22:32             ` Ævar Arnfjörð Bjarmason
2017-03-28  5:17               ` Jeff King
2017-03-28 13:13                 ` [PATCH/RFC v2] WIP configurable options facility Ævar Arnfjörð Bjarmason
2017-03-25 21:28         ` [PATCH/RFC] parse-options: add facility to make options configurable brian m. carlson
2017-03-20 10:42     ` Add configuration options for some commonly used command-line options Duy Nguyen

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACsJy8CQzo9K8N3xH_HJq=NjJVOUG9wawC4Mg+UuyFRZCPBpFw@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).