Re: [PATCH 1/4] Add '--fixed-strings' option to "git log --grep" and friends

[Junio C Hamano <gitster@pobox.com>]

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