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

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

quoted

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.

quoted

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