Re: [PATCH] Adds 'stash.index' configuration option

[Jeff King <peff@peff.net>]

On Thu, May 12, 2011 at 10:14:49AM +0200, Michael J Gruber wrote:

> > 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.
> > 
> 
> We haven't figured that out, but was the consensus: "Whatever, let's
> just keep adding single options." ?

I don't know. But short of coming up with a more global solution, what
do you want to do in the meantime? Forbid new config options of this
sort? I didn't see any consensus on that, either.

I'm not trying to be hostile, btw. I don't know what the right solution
is.

> > 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.
> 
> I just think we have too many commands which are ui and are used in
> scripts (e.g. log, commit, stash, just to name a few) for being able to
> decide that ourselves. Are we saying that people using "git stash" in a
> script have to deal themselves with a breakage caused by "--index" being
> a default for some users now?

I intentionally withheld any judgement on whether "stash --index" is a
safe option to add or not. I think that is a separate issue from whether
one should add such options, if they are considered safe.

> With a generic approach, we could protect all git-sh-setup using scripts
> right from the start, for example, while still allowing to override some
> options or to protect only a few (based on the explicit wishes of a
> uiopts-aware script).

Absolutely a solution like that would be better. Do you have a
particular proposal in mind? I know we've discussed it before, but I
didn't remember ever reaching any consensus on the right solution.

-Peff