From: Junio C Hamano <gitster@pobox.com>
To: Trevor Saunders <tbsaunde@tbsaunde.org>
Cc: Jeff King <peff@peff.net>, 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: Sat, 28 Feb 2015 19:06:16 -0800 [thread overview]
Message-ID: <xmqqvbilh0wn.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: 20150227100441.GA11861@tsaunders-iceball.corp.tor1.mozilla.com
Trevor Saunders <tbsaunde@tbsaunde.org> writes:
> There have been cases where I wanted grep to always ignore certain
> files, but to still get text diffs for those files. One case is people
> insist on using ChangeLog files, and another is people who commit
> generated files of one sort or another.
The attributes are to say "the contents to be stored in this file is
of this nature". Something inherent to the type of the contents,
and that is why there is no way to countermand them from the command
line.
The "nature of the content" may be "result of comparing two versions
of them textually will never make sense to humans", or "result of
finding substrings in them will never make sense to humans", which
are what "-diff" and hypothetical "-grep" mean, respectively.
"It is inconvenient that I see hits in ChangeLog files when I look
for string BUG" does not make ChangeLog inherently "result of
finding substrings in it never makes sense to humans"-kind of file
type. Maybe somebody who is playing a role of a coder right now may
not look at existing ChangeLog entries, but when that same person
plays the role of a release manager next day, running grep on older
ChangeLog files may become necessary to find changes related to
recent changes. For these "per-invocation" differences, attributes
to declare permenent/inherent nature of the contents is much less
suited than per-invocation inclusion/exclusion mechanism based on
pathspecs, I would think.
next prev parent reply other threads:[~2015-03-01 3:06 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
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 [this message]
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=xmqqvbilh0wn.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=noel@peralex.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=tbsaunde@tbsaunde.org \
/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.