git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Add configuration options for some commonly used command-line options

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 20, 2017, 18:56 UTC
Message-ID
<xmqq7f3jwzdo.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20170320173237.GA188475@google.com>
Brandon Williams <bmwill@google.com> writes:
Show 10 quoted lines
> If in the future we did want better support for making user defaults
> (apart from aliases) for commands we could entertain creating a command
> like bash's 'command' which ignores any user defaults and executes a
> particular command in a vanilla mode.
>
> So if the user configured 'git am' to always use the -3 option then
> running `git command am` (or something akin to that) would just run the
> vanilla 'am' command with no options.  Probably not the best idea since
> tooling would need to become aware of such a paradigm change, but its
> just a thought.

I do not think "command" is a good analogy. In practice it is used by those who want to create a wrapper that overrides a command for her own use, e.g. "ls () { command ls -AF "$@" }", in her .bashrc.

I suspect that it is too cumbersome for script writers to use for the purpose of protecting their scripts from random aliases that may change the behaviour of the commands their scripts want to rely on---they'll be forced to sprinkle practically each and every invocations of the basic UNIX building blocks with "command".

The saving grace for shell scripts is that the shell has good way to tell interactive and scripted use apart, by disabling aliases and not reading some rc files for non-interactive shells. Unfortunately I do not think "git" has the luxury of using that "hint" as a command invoked by these shells.

One thing we may want to consider is why we have to even worry about scripts getting broken. It is because people script around Porcelain, and that is because we have been too eager to improve Porcelain while neglecting plumbing for too long, to the point that some things are only doable with Porcelain (or doing the same with plumbing while possible are made too cumbersome). I find it quite disturbing that nobody brought that up as an issue that needs to be addressed in this entire thread.

Previous: Brandon McCaigNext: Jeff King
Message 9 of 19 in “Add configuration options for some commonly used command-line options (Was: [RFH] GSoC 2015 application)”
  1. Duy NguyenMar 19, 2017
  2. Matthieu MoyMar 19, 2017
  3. brian m. carlsonMar 19, 2017
  4. Ævar Arnfjörð BjarmasonMar 19, 2017
  5. Duy NguyenMar 20, 2017
  6. Brandon WilliamsMar 20, 2017
  7. Jeff KingMar 20, 2017
  8. Brandon McCaigMar 31, 2017
  9. Junio C HamanoMar 20, 2017
  10. Jeff KingMar 20, 2017
  11. Ævar Arnfjörð BjarmasonMar 20, 2017
  12. parse-options: add facility to make options configurableÆvar Arnfjörð Bjarmason, Mar 24, 2017
  13. Ævar Arnfjörð BjarmasonMar 25, 2017
  14. Jeff KingMar 25, 2017
  15. Ævar Arnfjörð BjarmasonMar 25, 2017
  16. Jeff KingMar 28, 2017
  17. WIP configurable options facilityÆvar Arnfjörð Bjarmason, Mar 28, 2017
  18. brian m. carlsonMar 25, 2017
  19. Duy NguyenMar 20, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.