Trevor Saunders [off-list ref] writes:
quoted
... 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?
On Sun, Mar 01, 2015 at 03:22:11PM -0800, Junio C Hamano wrote:
Trevor Saunders [off-list ref] writes:
quoted
quoted
... 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
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