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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.

> 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.