Re: feature request: excluding files/paths from git grep

2015-03-04 Thread Junio C Hamano
Noel Grandin n...@peralex.com writes:

 On 2015-03-02 02:50 PM, Trevor Saunders wrote:
 I think they solve somewhat different problems, but maybe my problem
 is so specialized I should just have a wrapper around grep that
 changes defaults. Trev 

 I'm with Trevor on this one. While I see the appeal of the generality
 of a macro solution, this is really just about convenience for me on a
 per-project basis.

 As in, while working on a specific project, I sometimes just want to
 exclude, for the time being, a bunch of stuff from 'git grep'.

The key word here is for the time being, though.  What would you
do once you are done with the for the time being activity?  git
config --unset?

If you forget to do so when the for the time being activity ends,
and then you try to run 'git grep' and see that you did not get
expected hits from hierarchies that you set to exclude earlier, you
either (1) get misled to a wrong decison based on that false
non-hit, or (2) start scratching your head, wasting time trying to
figure out why 'git grep' is not hitting, no?

I expect the answer might be No, I won't forget; I am very well
organized and you do not have to worry for me.  But a feature is an
invitation for people other than yourself, so...


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-03-04 Thread Junio C Hamano
Jeff King p...@peff.net writes:

 On Wed, Mar 04, 2015 at 12:56:10PM -0800, Junio C Hamano wrote:

  As in, while working on a specific project, I sometimes just want to
  exclude, for the time being, a bunch of stuff from 'git grep'.
 
 The key word here is for the time being, though.  What would you
 do once you are done with the for the time being activity?  git
 config --unset?

 IMHO this is being too paternalistic. You can already shoot yourself
 in the foot by configuring an alias to grep, running your alias, and
 wondering why it does not produce the results you wanted.

Yeah, as I said, it is a deliberately paternalistic stance.  But at
least when I say git mygrep using the alias mechanism and get a
result that is different from what I expect from git grep, I would
know I am doing something different with mygrep from grep, no?

And a great thing about that use alias approach is that we can
sidestep the entire then what should I do when I have to override
the configured thing for one-shot invocation? question, as there is
an obvious simple answer don't use that alias but use the
underlying command.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-03-04 Thread Jeff King
On Wed, Mar 04, 2015 at 12:56:10PM -0800, Junio C Hamano wrote:

  As in, while working on a specific project, I sometimes just want to
  exclude, for the time being, a bunch of stuff from 'git grep'.
 
 The key word here is for the time being, though.  What would you
 do once you are done with the for the time being activity?  git
 config --unset?

IMHO this is being too paternalistic. You can already shoot yourself
in the foot by configuring an alias to grep, running your alias, and
wondering why it does not produce the results you wanted.

But I'd also oppose a `grep.pathspecs` config option for a similar
reason: you can already accomplish the same thing (and more) with an
alias.

-Peff

PS One annoying thing about aliases is that you cannot re-alias an
   existing command, and git has already taken all of the good, easy
   names that we have trained our fingers for. :)

   Of course re-aliasing git-grep is another recipe for head-scratching
   (and broken scripts), but I am not sure there aren't a host of other
   ways to do a similar thing (basically any configuration option has
   the capacity to produce unexpected results if you forget that it is
   set).

   I dunno. Probably I am a bad person for dredging up that ancient
   argument again.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-03-04 Thread Noel Grandin

On 2015-03-02 02:50 PM, Trevor Saunders wrote:
I think they solve somewhat different problems, but maybe my problem is so specialized I should just have a wrapper 
around grep that changes defaults. Trev 


I'm with Trevor on this one. While I see the appeal of the generality of a macro solution, this is really just about 
convenience for me on a per-project basis.


As in, while working on a specific project, I sometimes just want to exclude, for the time being, a bunch of stuff from 
'git grep'.


Mind you, I use 'git grep' a hang of a lot during development, since it is so 
powerful, so maybe that's just me.

Thanks, Noel Grandin



Disclaimer: http://www.peralex.com/disclaimer.html


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-03-02 Thread Trevor Saunders
On Sun, Mar 01, 2015 at 03:22:11PM -0800, Junio C Hamano wrote:
 Trevor Saunders tbsau...@tbsaunde.org writes:
 
  ...  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.
 
  I think that makes some amount of sense, however typing stuff like
  --exclude=ChangeLog all the time is not terribly easy on the hands.
  Would it make sense to instead add a config variable grep.exclude?
 
 I do not think it makes much more sense for at least three reasons.
 for one thing, It still goes against per-invocation nature of what
 is being done.  Your for this invocation I do not want ChangeLog
 does not have to be limited to 'grep'.  And also I end up having to
 give these pathspecs all the time is not limited to negative ones.

I think what is somewhat special about grep is that I want to ignore a
set of paths such a large majority of the time that I really want to
change the default.  I could see someone wanting to do the same thing
for diff or log maybe, and so adding diff.exclude, but personally I
don't have a use for it.

 We have magic pathspecs, like This pattern is used to match the
 string case-insensitively, This pattern specifies that the path
 should *not* match it, etc.  How about adding a new feature that
 lets you say This is a short hand to giving these pathspecs and
 call that pathspec macro?
 
 If you get tired to keep having to type
 
 $ git log -- Documentation/ ':!Documentation/technical/'
 
 every time you want to check the end-user facing documentation
 pages, you could for example say (I am using a made-up 'macro'
 pathspec magic that is introduced by ':*' followed by a macro
 name):
 
 $ git log -- ':*userdoc'
 
 and the same macro specification could be used for all the other
 things that take pathspecs (grep, add, diff, etc.).

I can certainly see use cases for that, say
git log -- :!t/ :!foo/tests/ :!bar/testsuite/
to see what non test changes have happened in a project that doesn't
have a standardized name for test directories.

 You could then have something like this to define your own nolog
 macro:
 
 [pathspecMacro]
 nolog = ':!ChangeLog' ':!ChangeLog.*'
 
 to shorten your invocation of grep by appending it when you want
 to exclude some files, i.e.
 
 $ git grep -e pattern -- \*.c ':*nolog'
 
 and the same pathspec macro can be used in other places, not just
 grep.  Wouldn't it make more sense?

I think they solve somewhat different problems, but maybe my problem is
so specialized I should just have a wrapper around grep that changes
defaults.

Trev

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-03-01 Thread Junio C Hamano
Trevor Saunders tbsau...@tbsaunde.org writes:

 ...  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.

 I think that makes some amount of sense, however typing stuff like
 --exclude=ChangeLog all the time is not terribly easy on the hands.
 Would it make sense to instead add a config variable grep.exclude?

I do not think it makes much more sense for at least three reasons.
for one thing, It still goes against per-invocation nature of what
is being done.  Your for this invocation I do not want ChangeLog
does not have to be limited to 'grep'.  And also I end up having to
give these pathspecs all the time is not limited to negative ones.

We have magic pathspecs, like This pattern is used to match the
string case-insensitively, This pattern specifies that the path
should *not* match it, etc.  How about adding a new feature that
lets you say This is a short hand to giving these pathspecs and
call that pathspec macro?

If you get tired to keep having to type

$ git log -- Documentation/ ':!Documentation/technical/'

every time you want to check the end-user facing documentation
pages, you could for example say (I am using a made-up 'macro'
pathspec magic that is introduced by ':*' followed by a macro
name):

$ git log -- ':*userdoc'

and the same macro specification could be used for all the other
things that take pathspecs (grep, add, diff, etc.).

You could then have something like this to define your own nolog
macro:

[pathspecMacro]
nolog = ':!ChangeLog' ':!ChangeLog.*'

to shorten your invocation of grep by appending it when you want
to exclude some files, i.e.

$ git grep -e pattern -- \*.c ':*nolog'

and the same pathspec macro can be used in other places, not just
grep.  Wouldn't it make more sense?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-03-01 Thread Trevor Saunders
On Sat, Feb 28, 2015 at 07:06:16PM -0800, Junio C Hamano wrote:
 Trevor Saunders tbsau...@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.

I think that makes some amount of sense, however typing stuff like
--exclude=ChangeLog all the time is not terribly easy on the hands.
Would it make sense to instead add a config variable grep.exclude?

Trev

 
 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-28 Thread Junio C Hamano
Trevor Saunders tbsau...@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.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-27 Thread Michael J Gruber
Junio C Hamano venit, vidit, dixit 26.02.2015 21:59:
 Michael J Gruber g...@drmicha.warpmail.net writes:
 
 So, as a summary of the discussion, it seems it's time to switch the
 default to --textconv for git grep?
 
 Hmmm, why?
 
 Nobody seems to be asking for such a change in this thread.  The
 original issue IIRC was that the grep output was unnecessary for
 some paths and the repository did not mark these paths as such.
 Once they are marked as -diff, there is no reason why you want to
 trigger textconv to squelch the hits from grep.

Of course not. All that I want, and that I wanted back then, was to have
diff and grep behave the same.

 So that does not sound to me a summary of the discussion at all.
 

Well, your conditional

 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)
 
  - have git grep pay attention to diff.textconv and search in the
result of textconv filter.

and Jeff's Yes on that condition certainly read like that to me: Make
git grep react to diff, -diff attributes in the same way as git
diff.

But I've set up my alias greppp since then and don't care any more, and
I won't invest anything in this topic any more.

Michael
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-27 Thread Junio C Hamano
Michael J Gruber g...@drmicha.warpmail.net writes:

 Junio C Hamano venit, vidit, dixit 26.02.2015 21:59:

 So that does not sound to me a summary of the discussion at all.

 Well, your conditional

 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)
 
  - have git grep pay attention to diff.textconv and search in the
result of textconv filter.

 and Jeff's Yes on that condition certainly read like that to me: Make
 git grep react to diff, -diff attributes in the same way as git
 diff.

Ah, OK, I missed that flow of thought.

I read the conclusion as _if_ using diff attributes is enough for
this purpose, then there is no code to be written ... but 'grep' and
'diff' may want to be different.

Once we know if they do *not* want to be different, I agree that it
may make things more consistent to turn --textconv on for binary
files when running grep.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-27 Thread Trevor Saunders
On Wed, Feb 25, 2015 at 02:11:08PM -0500, Jeff King wrote:
 On Wed, Feb 25, 2015 at 11:01:22AM -0800, Junio C Hamano wrote:
 
  Jeff King p...@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. :)

 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.

 Trev

 
 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
 --
 To unsubscribe from this list: send the line unsubscribe git in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-26 Thread Michael J Gruber
Jeff King venit, vidit, dixit 25.02.2015 20:11:
 On Wed, Feb 25, 2015 at 11:01:22AM -0800, Junio C Hamano wrote:
 
 Jeff King p...@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
 

So, as a summary of the discussion, it seems it's time to switch the
default to --textconv for git grep?

Michael
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


feature request: excluding files/paths from git grep

2015-02-25 Thread Noel Grandin

Hi

In our repo (LibreOffice) we have various test files which tend to show up on 
'grit grep',
which just generate noise because
(a) they have lots of common keywords that one might search for in them
and
(b) they have very little in the way of linebreaks

So they tend to generate a lot of noise when searching.

What would be nice is a per-user/repo config setting that excludes certain 
files and paths from the 'git grep' search.

Does this sound reasonable/acceptable?

Thanks, Noel Grandin

Disclaimer: http://www.peralex.com/disclaimer.html


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-25 Thread Jeff King
On Wed, Feb 25, 2015 at 08:46:37PM +0700, Duy Nguyen wrote:

 On Wed, Feb 25, 2015 at 7:23 PM, Noel Grandin n...@peralex.com wrote:
  What would be nice is a per-user/repo config setting that excludes certain
  files and paths from the 'git grep' search.
 
  Does this sound reasonable/acceptable?
 
 There is no config setting to do that, but since v1.9.5 you can use
 ':!' or ':(exclude) to exclude paths, for example
 
 git grep foo -- '*.c' ':!src/ ':!*foo*.c'
 
 will exclude .c files in src directory or contains foo. If you use
 some exclude patterns often, you can write a short script. Perhaps we
 could support pathspec macros (similar to git-attr macros), stored in
 config file. You still need to type, but it'll be a lot shorter.

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.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-25 Thread Duy Nguyen
On Wed, Feb 25, 2015 at 7:23 PM, Noel Grandin n...@peralex.com wrote:
 What would be nice is a per-user/repo config setting that excludes certain
 files and paths from the 'git grep' search.

 Does this sound reasonable/acceptable?

There is no config setting to do that, but since v1.9.5 you can use
':!' or ':(exclude) to exclude paths, for example

git grep foo -- '*.c' ':!src/ ':!*foo*.c'

will exclude .c files in src directory or contains foo. If you use
some exclude patterns often, you can write a short script. Perhaps we
could support pathspec macros (similar to git-attr macros), stored in
config file. You still need to type, but it'll be a lot shorter.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-25 Thread Jeff King
On Wed, Feb 25, 2015 at 10:33:53AM -0800, Junio C Hamano wrote:

 Jeff King p...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-25 Thread Junio C Hamano
Jeff King p...@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?

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)

 - have git grep pay attention to diff.textconv and search in the
   result of textconv filter.


 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-25 Thread Junio C Hamano
Jeff King p...@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.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: feature request: excluding files/paths from git grep

2015-02-25 Thread Jeff King
On Wed, Feb 25, 2015 at 11:01:22AM -0800, Junio C Hamano wrote:

 Jeff King p...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html