Junio C Hamano [off-list ref] writes:
Junio C Hamano [off-list ref] writes:
quoted
* "git grep" learned to use a non-standard pattern type by default if
a configuration variable tells it to.
This addition makes
git grep -e "(integer|buffer)"
work as expected, when grep.patternType is set to "extended".
Should this
git log --grep="(integer|buffer)"
also honor the same configuration variable? If not, why not?
One more thing. Currently you can say
git log -E --grep="(integer|buffer)"
to ask for the ERE. Should we also support -P to ask for pcre? If
not, why not?
Answering to myself who has been in tying-loose-ends mode.
My answers to these questions are both yes, and I have a neatly
lined up series that begins with a small bugfix and then
enhancement, but I do not think these do not deserve to in the
upcoming release. The topic came too late, and even the fix is
for a bug that has been with us for a long time.
Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
Junio C Hamano [off-list ref] writes:
quoted
* "git grep" learned to use a non-standard pattern type by
default if a configuration variable tells it to.
This addition makes
git grep -e "(integer|buffer)"
work as expected, when grep.patternType is set to "extended".
Should this
git log --grep="(integer|buffer)"
also honor the same configuration variable? If not, why not?
I think this should respect grep.patternType.
quoted
One more thing. Currently you can say
git log -E --grep="(integer|buffer)"
to ask for the ERE. Should we also support -P to ask for pcre? If
not, why not?
This also.
Answering to myself who has been in tying-loose-ends mode.
My answers to these questions are both yes, and I have a neatly
lined up series that begins with a small bugfix and then
enhancement, but I do not think these do not deserve to in the
upcoming release. The topic came too late, and even the fix is
for a bug that has been with us for a long time.
I think I am the one to blame for this inconsistency. When I
implemented "git-grep -P" I was thinking about making it work for all
regex operations in git but since I'm mostly using regexes with
git-grep I was too lazy to make it work with git-log.
On Wed, Oct 3, 2012 at 6:14 PM, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
Junio C Hamano [off-list ref] writes:
quoted
* "git grep" learned to use a non-standard pattern type by default if
a configuration variable tells it to.
This addition makes
git grep -e "(integer|buffer)"
work as expected, when grep.patternType is set to "extended".
Should this
git log --grep="(integer|buffer)"
also honor the same configuration variable? If not, why not?
One more thing. Currently you can say
git log -E --grep="(integer|buffer)"
to ask for the ERE. Should we also support -P to ask for pcre? If
not, why not?
Answering to myself who has been in tying-loose-ends mode.
My answers to these questions are both yes, and I have a neatly
lined up series that begins with a small bugfix and then
enhancement, but I do not think these do not deserve to in the
upcoming release. The topic came too late, and even the fix is
for a bug that has been with us for a long time.
Yeah, I think that could be useful and consistent. I took a look at
the grep situation in the log command briefly when writing the
original patch but ended up leaving it as-is as for the time being due
to time constraints and the like. But yeah, that behaviour is
definitely desirable. I think any commands that work with grep should
probably follow suit, for that matter. (Are there others other than
log and grep itself...?)