Jakub Narebski <jnareb@xxxxxxxxx> 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 <jnareb@xxxxxxxxx>
> ---
> 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.
-
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
