From: A Large Angry SCM <gitzilla@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] grep: --full-tree
Date: Wed, 25 Nov 2009 18:07:00 -0500 [thread overview]
Message-ID: <4B0DB894.7010800@gmail.com> (raw)
In-Reply-To: <20091125225318.GA10127@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:
>
>>> I agree with all of this as far as changing the default goes. But the
>>> point of my earlier messages was that I don't think there _is_ one sane
>>> default. I really do want it different per-project. And that means a
>>> configuration option.
>> Since grep is so useful, both interactively and scripted, outside of
>> git, this is a pretty convincing argument that git-grep, and all
>> other git commands with configurable behavior or defaults that change
>> over time, need a both a scripting form and an interactive form.
>
> It is tempting to have scripts simply set a GIT_VANILLA environment
> variable to ignore config options. But I think it is not quite so
> simple. As a script, if I am calling "git log", do I want it to respect
> the user's colorization config or not? It depends on _how_ I am calling
> it. Is the output to be shown to the user, or am I going to process it
> myself?
>
> Similarly, why is the script calling "git grep"? If it is because the
> script is a convenience wrapper (e.g., let's say to colorize the output
> in a particular way), then it probably wants to respect my configured
> choice of which files to grep. But if the script is just using "git
> grep" to get data to perform some other calculation, then it probably
> does care deeply about which set of files to grep.
>
> So I think you have situations where scripts do want to invoke the
> porcelain version of a command versus the plumbing. But much harder, you
> have ones where they want to respect some options but not others.
<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>
next prev parent reply other threads:[~2009-11-25 23:07 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 [this message]
2009-11-25 23:22 ` Jeff King
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=4B0DB894.7010800@gmail.com \
--to=gitzilla@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.