threads / discuss / 14501

Patterns work unexpectedly with "git log" commit limiting

Subject: Patterns work unexpectedly with "git log" commit limiting

## tl;dr

3 messages between Jul 17, 2008 and Jul 17, 2008.

replies: 2people: 3as markdown or json

Teemu Likonen· Jul 17, 2008, 07:47 UTC · lore

It looks to me that some commit limiting options used with "git log" work a bit buggyish or unexpectedly. Please don't take this as a rant; I only mean to express some unexpected behaviour in the user interface. You can be sure that I don't understand the plumbing stuff and implementation details.

 1. Option order changes the behaviour. "git log" with
	-E --author=pattern
    interprets "pattern" as _basic_ regexp. To have it interpreted as
    extended regexp the order must be
	--author=pattern -E
    
    BUT the "pattern" in
	--author=non-matching-nonsense -E --author=pattern
    is interpreted as extended regexp. So -E's behaviour depens on the
    preceding options.
 2. Internally --author= and --committer= fields contain more stuff than
    just person's name and email address. I mean user might expect
	--author='@iki.fi>$'
    to match all authors with this email host/domain. It took quite some
    time for me to realise that the (usually hidden) raw author field
    contains also date information, such as "1216023662 +0300". Well,
    not a big deal but certainly unexpected in the context of commit
    limiting by author.
 3. What is the supposed behaviour of -F (--fixed-strings) when combined
    with --author= ?
	--author=pattern -F
    doesn't seem to match anything. I also tried putting the entire raw
    author field (i.e. including the raw date) but no match. With -F
    before the --author= it behaves like no -F at all.
    "--grep=fixedstring -F" seems to work, though.
 4. Logical AND/OR operation. I realised that several commit limiting
    options combined together do not limit commits more but the
    opposite. So it seems like a logical OR operation between the
    limiting options. It's fine. It's just that I'd have expected that
    more limiting options means limiting more (i.e. the AND operation,
    just like in the "find" command normally).
    
    Well, unexpected but I'll survive. Shouldn't this be mentioned under
    the title "Commit Limiting" in the man page? (My English is not
    really manual-writing quality but I could try to come up with
    a patch.)
Junio C Hamano· Jul 17, 2008, 08:17 UTC · re: Teemu Likonen · lore

Re: Patterns work unexpectedly with "git log" commit limiting

Teemu Likonen <tlikonen@iki.fi> writes:
Show 5 quoted lines
>  1. Option order changes the behaviour. "git log" with
> ...
>  2. Internally --author= and --committer= fields contain more stuff than
> ...
>  3. What is the supposed behaviour of -F (--fixed-strings) when combined

I won't have time right now to comment on the previous three, because they are not my code (meaning, I need to dig around before I can intelligently answer -- maybe when I have free time). What you expected does sound very sensible, though.

>  4. Logical AND/OR operation.

The --grep and --author search of "log" family shares git-grep logical expression engine, so if you somehow can come up with a way to pass --and (or even better, --all-match) from the command line just like we can give them to git-grep, searching with combinations of and/or/not should be doable.

Petr Baudis· Jul 17, 2008, 08:59 UTC · re: Teemu Likonen · lore

Re: Patterns work unexpectedly with "git log" commit limiting

  Hi,
On Thu, Jul 17, 2008 at 10:47:06AM +0300, Teemu Likonen wrote:
Show 10 quoted lines
>  3. What is the supposed behaviour of -F (--fixed-strings) when combined
>     with --author= ?
> 
> 	--author=pattern -F
> 
>     doesn't seem to match anything. I also tried putting the entire raw
>     author field (i.e. including the raw date) but no match. With -F
>     before the --author= it behaves like no -F at all.
> 
>     "--grep=fixedstring -F" seems to work, though.
  this is actually very high on my TODO list, since it makes
author/committer search in gitweb disfunctional. I plan to post a patch
fixing this in a few days, unless someone beats me to it as usual. ;-)
				Petr "Pasky" Baudis

← back to recent threads