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