Trevor Saunders <tbsaunde@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html