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 13:51:28 -0500 [thread overview]
Message-ID: <20150225185128.GA16569@peff.net> (raw)
In-Reply-To: <xmqqk2z5on72.fsf@gitster.dls.corp.google.com>
On Wed, Feb 25, 2015 at 10:33:53AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > If it's an attribute of the file, and not the request, maybe
> > gitattributes would be a better fit. You can already do this with:
> >
> > *.foo -diff
> >
> > in your .gitattributes file, though that _also_ marks the files as "not
> > for diffing", which may not be desired. There's not a separate "grep"
> > attribute, but I do not think it would be unreasonable to add one.
>
> I have a vague recollection of having a discussion that started with
> something like this:
>
> "diff" is named as if it is only for "diff" for historical
> reasons, but it is about "do we want to treat its raw contents
> as text?"
Yes, I think we had this discussion, and agreed that is a reasonable
definition...
> I do not recall its conclusion, but it it were "Yes, that is what it
> means", then it might be reasonable to:
>
> - have "git grep" ignore paths marked with -diff by default
> (perhaps "-a" option to disable, just like GNU)
...which led to 41b59bf (grep: respect diff attributes for binary-ness,
2012-02-02)...
> - have "git grep" pay attention to diff.textconv and search in the
> result of textconv filter.
..and 335ec3b (grep: allow to use textconv filters, 2013-05-10).
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).
-Peff
next prev parent reply other threads:[~2015-02-25 18:51 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 [this message]
2015-02-25 19:01 ` Junio C Hamano
2015-02-25 19:11 ` Jeff King
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=20150225185128.GA16569@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.