git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
May 12, 2011, 08:14 UTC
Message-ID
<4DCB96F9.2020700@drmicha.warpmail.net>
In-Reply-To
<20110512080425.GA11870@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 12.05.2011 10:04:
Show 37 quoted lines
> 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.
> 

We haven't figured that out, but was the consensus: "Whatever, let's just keep adding single options." ?

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

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

Michael
Previous: Jeff KingNext: Jeff King
Message 8 of 14 in “Adds 'stash.index' configuration option”
  1. Adds 'stash.index' configuration optionDavid Pisoni, May 11, 2011
  2. Junio C HamanoMay 11, 2011
  3. Junio C HamanoMay 12, 2011
  4. David PisoniMay 12, 2011
  5. Junio C HamanoMay 12, 2011
  6. Michael J GruberMay 12, 2011
  7. Jeff KingMay 12, 2011
  8. Michael J GruberMay 12, 2011
  9. Jeff KingMay 12, 2011
  10. RFC proposal: set git defaults options from configMichael J Gruber, May 12, 2011
  11. David PisoniMay 12, 2011
  12. Jeff KingMay 16, 2011
  13. Jeff KingMay 16, 2011
  14. Michael J GruberMay 16, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.