Junio C Hamano wrote:
> 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 ;-).
What I meant here that gitweb using --fixed-strings option for
commit message search is example usage of this new feature.
Otherwise we would have to have in gitweb original $searchtext
(for links, description, page title, etc.), $search_grep_regexp
(for grep, or rather for "git log --grep" and friends, basic/extended
regexp meta quoted), and finally $search_regexp to be used in gitweb,
i.e. in Perl to show match.
> 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.
I have written it this way not only because it is simpler than correct
escaping, but also because git-grep has this option (consistency).
Besides it was very easy to add.
> 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.
Feel free to drop support for '-F' short option then, both in code
and in documentation.
I have checked that git-log doesn't support '-F' short option;
additionally '-F' is used in git commands as '--file', i.e. "-F <file>"
to get contents (commit message, tag comment/message). Therefore it was
unlikely that "git log" and friends would acquire "-F <file>" option.
> 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.
Errr... to be sure I don't know. From what I have checked it shows
"nothing found", but I guess it could be more explicit.
--
Jakub Narebski
Poland
-
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
