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