From: Jeff King <peff@peff.net>
To: A Large Angry SCM <gitzilla@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] grep: --full-tree
Date: Wed, 25 Nov 2009 18:22:10 -0500 [thread overview]
Message-ID: <20091125232210.GA15538@coredump.intra.peff.net> (raw)
In-Reply-To: <4B0DB894.7010800@gmail.com>
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
next prev parent reply other threads:[~2009-11-25 23:22 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-24 8:56 [PATCH] grep: --full-tree Junio C Hamano
2009-11-25 13:16 ` Michael J Gruber
2009-11-25 19:32 ` Junio C Hamano
2009-11-25 14:56 ` Sverre Rabbelier
2009-11-25 19:32 ` Junio C Hamano
2009-11-25 20:19 ` Sverre Rabbelier
2009-11-25 20:23 ` Junio C Hamano
2009-11-25 20:46 ` Sverre Rabbelier
2009-11-25 23:31 ` Johannes Schindelin
2009-11-25 23:29 ` Sverre Rabbelier
2009-11-25 20:52 ` Jeff King
2009-11-25 20:39 ` Jeff King
2009-11-25 20:52 ` Junio C Hamano
2009-11-25 21:00 ` Jeff King
2009-11-25 21:33 ` Junio C Hamano
2009-11-25 21:49 ` Jeff King
2009-11-25 22:12 ` James Pickens
2009-11-25 22:20 ` Jeff King
2009-11-26 17:56 ` James Pickens
2009-11-27 6:20 ` Jeff King
2009-11-27 8:18 ` Junio C Hamano
2009-11-27 9:31 ` Johannes Schindelin
2009-11-27 9:59 ` Jeff King
2009-11-27 10:53 ` Johannes Schindelin
2009-11-27 16:27 ` Uri Okrent
2009-11-27 18:29 ` Junio C Hamano
2009-11-27 18:47 ` Uri Okrent
2009-11-27 20:53 ` Jeff King
2009-11-29 19:50 ` Uri Okrent
2009-11-29 11:48 ` Felipe Contreras
2009-11-27 18:02 ` Jeff King
2009-11-27 20:07 ` Johannes Schindelin
2009-11-27 21:05 ` Jeff King
2009-11-29 10:28 ` Johannes Schindelin
2009-11-29 18:32 ` Jeff King
2009-11-29 19:49 ` Junio C Hamano
2009-11-29 12:13 ` Felipe Contreras
2009-11-27 18:29 ` Junio C Hamano
2009-11-27 20:50 ` Jeff King
2009-11-29 10:21 ` Johannes Schindelin
2009-11-29 18:24 ` Jeff King
2009-11-27 10:37 ` Matthieu Moy
2009-11-27 10:56 ` Johannes Schindelin
2009-11-25 22:26 ` Wincent Colaiuta
2009-11-26 0:00 ` Junio C Hamano
2009-11-26 0:16 ` A Large Angry SCM
2009-11-26 0:20 ` Junio C Hamano
2009-11-26 0:30 ` A Large Angry SCM
2009-11-26 0:36 ` Junio C Hamano
2009-11-26 18:14 ` James Pickens
2009-11-25 22:19 ` Junio C Hamano
2009-11-25 22:26 ` Jeff King
2009-11-25 22:41 ` A Large Angry SCM
2009-11-25 22:53 ` Jeff King
2009-11-25 23:07 ` A Large Angry SCM
2009-11-25 23:22 ` Jeff King [this message]
2009-11-29 11:38 ` Felipe Contreras
2009-11-29 19:45 ` Uri Okrent
2009-11-26 0:02 ` Junio C Hamano
2009-11-27 6:22 ` Jeff King
2009-11-25 22:15 ` A Large Angry SCM
2009-11-25 22:21 ` Junio C Hamano
2009-11-25 22:31 ` A Large Angry SCM
2009-11-25 22:43 ` A Large Angry SCM
2009-11-25 23:34 ` Johannes Schindelin
2009-11-25 23:41 ` Junio C Hamano
2009-11-26 0:04 ` Johannes Schindelin
2009-11-26 0:13 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091125232210.GA15538@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=gitzilla@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).