Duy Nguyen <pclouds@xxxxxxxxx> writes:
> On Thu, Feb 19, 2015 at 5:32 PM, Matthieu Moy
> <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
>> +### Add configuration options for some commonly used command-line options
>> +
>> +This includes:
>> +
>> +* git am -3
>> +
>> +* git am -c
>> +
>> +Some people always run the command with these options, and would
>> +prefer to be able to activate them by default in ~/.gitconfig.
>
> I was reading the .md file to add a new microproject and found this.
> Instead of adding new config case by case, should we do something more
> generic?
>
> We could have a new group defaultOptions.<command> (or
> <command>.options) which contains <option-name> = <value> where option
> names are the long name in parse-options? Then we don't have to
> manually add more config options any more (mostly, I'm aware of stuff
> like diff options that do not use parse-options).
>
> If we want to stop the users from shooting themselves in the foot, we
> could extend parse-options to allow/disallow certain options being
> used this way. Hmm?
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".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/