On Thu, May 12, 2011 at 09:14:09AM +0200, Michael J Gruber wrote:
> This is yet another incarnation of
>
> foo.bar = true
>
> meaning that command "git foo" defaults to "git foo --bar". (Admittedly,
> this is about subcommands of foo.)
>
> It has the same problems (possibly breaking scripts). But more
> importantly, it inflates the code with every such incarnation we add.
> Have we really agreed that we introduce these one-by-one rather than
> doing something generic like
>
> uiopts.<cmd> = <optionlist>
>
> with which you would do
>
> uiopts.stash = "--index"
>
> and hopefully be script-safe (again, ignoring the subcommand issue)?
I would love to see something like this, but have we yet figured out all
of the issues, like:
1. How do scripts wanting to call git programs suppress expansion of
uiopts when they want predictable behavior?
2. Depending on the solution to (1), how do scripts specify that they
_do_ want to allow uiopts (e.g., because they know they are
presenting the output to the user) for certain commands?
3. Depending on (1) and (2), how do scripts differentiate when some
options are OK in uiopts, but others are not? For example, it may
be desirable for an invocation of diff-tree to have renames turned
on by the user, but not for them to change the output format.
As much as it sucks to have a config option for each individual option,
there is at least some oversight of which options will not cause too
much of a problem when triggered automatically.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html