Why does "git log --author=<pattern>" not work with "regexp-ignore-case" and other regexp-related options?

Why does "git log --author=<pattern>" not work with "regexp-ignore-case" and other regexp-related options?

[Tim Friske]

Hi,

I wonder why "git log --author=<pattern>" does not work with the
"regexp-ignore-case" option and the other regexp-related options?
Wouldn't it be useful to make the "author=<pattern>" option support the
following options?

  * basic-regexp
  * extended-regexp
  * fixed-strings
  * perl-regexp

In the same way "git log --committer=<pattern>" cannot be combined with
any of the above options.

I tried to find out which regexp dialect to use for the "<pattern>"
argument that must be passed to the "author" and "committer" options but
without luck. The git-log(1) manual page just states for these options
"... that match the specified pattern (regular expression)".

Given a commit with the following headers:

Author: Tim Friske <me@tifr.de>
Commit: Tim Friske <me@tifr.de>

When running "git log --author='tim|friske' --regexp-ignore-case" I
would expect a match because lower- and upper case characters are
treated as equal.

When running "git --log --author='Tim|Friske' --fixed-strings" I would
expect *no* match because the string 'Tim|Friske' should be taken
literally and not be interpreted as a pattern.

When running "git --log --author='Tim|Friske' --basic-regexp" I would
expect *no* match because basic regular expression syntax does not
support "|" alternation.

Wouldn't it be nice to have all of the above options collaborate with
each other?

BR
Tim

Re: Why does "git log --author=<pattern>" not work with "regexp-ignore-case" and other regexp-related options?

[Junio C Hamano]

Tim Friske <me@tifr.de> writes:

> I wonder why "git log --author=<pattern>" does not work with the
> "regexp-ignore-case" option and the other regexp-related options
> Wouldn't it be useful to make ...

I think the reason is because nobody bothered to make it so.  That
does not necessarily say what you suggest is not useful, but if it
were so very much useful in the real world, perhaps somebody may
have already been motivated enough to make it so, and the fact that
it has not happened might be an indirect indication of its predicted
usefulness.  I dunno.

In any case, I do not offhand see how it would _hurt_ if we added
such a feature.  The only reason it may hurt existing users would be
that people may depend on the current behaviour, trusting that
exactly spelling --author=Tim option, when using case-ignoring
matching of --grep=<pattern> to find the <pattern> in the log string
filters out the other tim whose name is spelled with lowercase.
Your proposed new world order _will_ break such users.  But I do not
think it is very likely to become a real-world issue.

Of course, if the implementation is done poorly, it _will_ hurt the
overall performance or maintainability and that would make such an
implementation unacceptable, but that is a separate matter---it does
not reject the feature, just a specific poor implementation.

So a patch to do so cleanly with proper tests is very much welcomed.

The same comment applies to your other "wouldn't it be wonderful if
-G<pattern> became case-insensitive with an option?" topic (but as I
already said, -S<string> is *not* -G<string> with --fixed-strings).

Thanks.