Re: [PATCH] grep: --full-tree

From: Jeff King <peff@peff.net>
Date: Nov 25, 2009, 23:22 UTC
Message-ID: <20091125232210.GA15538@coredump.intra.peff.net>
In-Reply-To: <4B0DB894.7010800@gmail.com>

On Wed, Nov 25, 2009 at 06:07:00PM -0500, A Large Angry SCM wrote:

Show 13 quoted lines

> <semi rhetorical>
> So, what's the solution?
> 
> Have every command command take a list of configuration options to
> ignore/respect?
> 
> Have every command take an option to ignore/respect _all_
> configuration options?
> 
> Have inconsistency between commands, like we have now
> 
> Have commands have all kinds of hidden/undocumented default settings?
> </semi rhetorical>

I don't know. All of those options suck. ;

Probably we would want something flexible, but with sane defaults. Like an environment variable to ignore all (or most) config options, but then the ability to opt into specific ones. Something like:

  GIT_PLUMBING=1; export GIT_PLUMBING
  git log ;# does not respect any non-plumbing config
  git --respect='log.showroot' ;# respect just the one variable
  git --respect='color.*' log ;# you get all color

But there are two big obstacles (besides the obvious issue that introducing this in itself needs a gentle transition plan):

  1. We need to annotate every config option with whether it is
     potentially problematic. For example, core.filemode should probably
     be respected no matter what (but I'm not sure if it is simply true
     for core.*).

  2. Script writers need to actually use the system, which is somewhat
     more verbose and annoying than what they have to do now. But at
     least it defaults to safety when they are lazy, and then they can
     re-add options. Of course, they are stuck on an upgrade treadmill
     of analyzing and approving each new option that appears in git.

-Peff