git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Teemu Likonen <tlikonen@iki.fi>
To: git@vger.kernel.org
Subject: Patterns work unexpectedly with "git log" commit limiting
Date: Thu, 17 Jul 2008 10:47:06 +0300	[thread overview]
Message-ID: <20080717074706.GA5392@mithlond.arda.local> (raw)

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.)

             reply	other threads:[~2008-07-17  7:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-17  7:47 Teemu Likonen [this message]
2008-07-17  8:17 ` Patterns work unexpectedly with "git log" commit limiting Junio C Hamano
2008-07-17  8:59 ` Petr Baudis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080717074706.GA5392@mithlond.arda.local \
    --to=tlikonen@iki.fi \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).