From: Ævar Arnfjörð Bjarmason <email@example.com> To: "brian m. carlson" <firstname.lastname@example.org>, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>, Duy Nguyen <email@example.com>, Jeff King <firstname.lastname@example.org>, Git Mailing List <email@example.com> Subject: Re: Add configuration options for some commonly used command-line options Date: Sun, 19 Mar 2017 14:43:33 +0100 Message-ID: <CACBZZX4FksU6NujPZ_3GZ45EQ+KdJj5G2sajtRipE1wbaA3URA@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Sun, Mar 19, 2017 at 2:18 PM, brian m. carlson <email@example.com> 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. > I tend to agree here. At work, we have code that wants git status > --porcelain to be empty. If a user added -b to all of their git status > calls (to make -s output more helpful), that would break a lot of > tooling. It's much better if they create an alias, since that doesn't > affect automated tools. With the caveat I noted above this would be a complete non-issue, i.e. we'd just pass some option to the getopt for --porcelain which would disable any other option slurping up its configuration from a config file. > I expect developers of things such as fugitive would dislike such a > feature as well. I get the impression our existing config file options > already make life difficult enough. I don't know if this is what Duy has in mind, but the facility I've described is purely an internal code reorganization issue. I.e. us not having to write custom code for each bultin every time we want to take an option from the command line || config. It does make it *easier* to flag more options as "this is configurable", but whether that flag is turned on for each command/option is just something we could discuss on-list on a case-by-case basis.
next prev parent reply index Thread overview: 17+ 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 [this message] 2017-03-20 10:56 ` Duy Nguyen 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-25 21:28 ` 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 publically 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=CACBZZX4FksU6NujPZ_3GZ45EQ+KdJj5G2sajtRipE1wbaA3URA@mail.gmail.com \ --firstname.lastname@example.org \ --cc=Matthieu.Moy@grenoble-inp.fr \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
email@example.com mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox