From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Duy Nguyen <pclouds@gmail.com>, Noel Grandin <noel@peralex.com>,
git <git@vger.kernel.org>
Subject: Re: feature request: excluding files/paths from "git grep"
Date: Wed, 25 Feb 2015 14:11:08 -0500 [thread overview]
Message-ID: <20150225191108.GA17467@peff.net> (raw)
In-Reply-To: <xmqqbnkholx9.fsf@gitster.dls.corp.google.com>
On Wed, Feb 25, 2015 at 11:01:22AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So I think _if_ using "diff" attributes is enough for this purpose, then
> > there is no code to be written. But if somebody wants to draw a
> > distinction between the uses (I want to diff "foo" files, but never see
> > them in grep) then we could introduce a "grep" attribute (with the
> > fallback being the value of the "diff" attribute for that path).
>
> That is all true.
>
> If we were to have a new 'grep' attribute that can be used to
> express 'It is OK to diff two versions of this path, but hits by
> grep in this path is useless' (and verse versa), the built-in macro
> attribute 'binary' should also be updated with it. A path being
> 'binary' currently means '-diff -merge -text' but it should also
> mean '-grep' in the new world, if we were to go in that direction.
I think it would do so automatically. There is no "grep" attribute
given, so we fall back to the "-diff" attribute. But I do not mind
modifying the macro to be more explicit.
Note also that I am not volunteering to work on this, nor am I convinced
it's actually worth pursuing. I've yet to see a useful case where you
would want text diffs but not greps (or vice versa), and if we can avoid
cluttering the attribute space, we should. I was mostly pointing it out
that it is not logically inconsistent to want such a thing. :)
If somebody does look into it, I suspect the place to start is modifying
userdiff_find_by_path to optionally prefer "grep" to "diff".
-Peff
next prev parent reply other threads:[~2015-02-25 19:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-25 12:23 feature request: excluding files/paths from "git grep" Noel Grandin
2015-02-25 13:46 ` Duy Nguyen
2015-02-25 14:31 ` Jeff King
2015-02-25 18:33 ` Junio C Hamano
2015-02-25 18:51 ` Jeff King
2015-02-25 19:01 ` Junio C Hamano
2015-02-25 19:11 ` Jeff King [this message]
2015-02-26 11:16 ` Michael J Gruber
2015-02-26 11:58 ` Duy Nguyen
2015-02-26 20:59 ` Junio C Hamano
2015-02-27 15:13 ` Michael J Gruber
2015-02-27 19:17 ` Junio C Hamano
2015-02-27 10:04 ` Trevor Saunders
2015-03-01 3:06 ` Junio C Hamano
2015-03-01 13:03 ` Trevor Saunders
2015-03-01 23:22 ` Junio C Hamano
2015-03-02 12:50 ` Trevor Saunders
2015-03-04 11:25 ` Noel Grandin
2015-03-04 20:56 ` Junio C Hamano
2015-03-05 5:22 ` Jeff King
2015-03-05 6:03 ` 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=20150225191108.GA17467@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=noel@peralex.com \
--cc=pclouds@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 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.