On Mon, Mar 20, 2017 at 10:32:37AM -0700, Brandon Williams wrote: > > > 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. > > 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 think we've had similar proposals in the form of an environment variable like "GIT_PLUMBING" (and your "command", which I do like syntactically, would probably just end up setting such an environment variable anyway). But yeah, the sticking point is that we'd have to wait for scripts to adopt it. Manually marking options as "safe" is tedious, but gives more control. If we want to follow the GIT_PLUMBING route, I think the first step would be to introduce it now as a noop (or even a mostly-noop that just turns off eve the "safe" options). And then we wait for N time units so that scripts can start using it, and only then start introducing the breaking changes. -Peff