Jakub Narebski [off-list ref] writes:
Add support for -F | --fixed-strings option to "git log --grep"
and friends: "git log --author", "git log --committer=<pattern>".
Code is based on implementation of this option in "git grep".
Signed-off-by: Jakub Narebski <redacted>
---
This would simplify ignore-case searching for a fixed string from
within gitweb, as gitweb wouldn't then have to deal with differences
in quoting and unquoting (if you quote character which doesn't need
quoting, would git (grep) unquote it?) between searched phrase,
basic/extended regular expression as understood by git/by grep,
and regular expressions in Perl (when showing matched info).
[I am not sure if the above paragraph should be added to commit
message, so it is in patch comments. Feel free to add it.]
I do not understand the issue from reading that paragraph, so it
probably means that (1) it does not help even if it is in the
commit log message, and/or (2) more readable explanation may
help in the commit log message ;-).
The rule for grep input should be known by anybody who writes
scripts around grep, so I do not think this patch is absolutely
necessary if this is only for gitweb. But for command line
end-user usage, fixed string search _might be_ useful, although
I've personally never felt need for that. So I am reluctant to
see it grab a short-and-sweet -F option letter that might have
better uses, but I do not have major objection against a more
explicit --fixed-strings.
By the way, do you allow the default regexp search in gitweb?
If so, how do you handle a malformed regexp that a user gives
you? For example,
$ git log --grep="don\('t" -1
barfs, and I suspect that you can catch the exit status 128 from
die() and say something other than "nothing found" if you really
wanted to.