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

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

Tim Friske <me@tifr.de> writes:

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.