On Wed, Nov 25, 2009 at 06:07:00PM -0500, A Large Angry SCM wrote:
> <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
--
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