From: Junio C Hamano <gitster@pobox•com>
To: Michael J Gruber <git@drmicha•warpmail.net>
Cc: Tim Friske <me@tifr•de>, git <git@vger•kernel.org>
Subject: Re: Why does "git log -G<regex>" works with "regexp-ignore-case" but not with other regexp-related options?
Date: Mon, 20 Apr 2015 10:41:51 -0700 [thread overview]
Message-ID: <xmqqbniin1cw.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <5534BD87.8020709@drmicha.warpmail.net> (Michael J. Gruber's message of "Mon, 20 Apr 2015 10:49:11 +0200")
Michael J Gruber <git@drmicha•warpmail.net> writes:
> They [jc: -S and -G] have different semantics, and *therefore*
> they have different defaults, and *therefore* a user may want to
> switch one of them (or --grep or --author or...) to
> --fixed--strings and keep the other to --regexp.
Ahh, OK. And not just -S and -G, the "fields in headers" may be
something user may want to switch independently?
> One idea would be to make
>
> --regexp -S --fixed-strings -G
>
> work the obvious way (match option affects following grep
> options),...
I understand that your idea is for options to accumulate up to what
consumes them, e.g. -S, -G, --author,..., and then get reset for the
next consumer. I would think it is very much debatable if that way
of working is "the obvious" one, though. If I had no prior Git
experience, I would imagine that I would find it more intuitive if
$ git log --regexp-ignore-case --author=tiM --grep=wip
showed a commit authored by Tim that is labelled with "[WIP]".
It may be tempting to expose that our underlying machinery could use
3 different regexp matching settings for header fields (i.e. author,
committer), log messages and the patch bodies somehow to the end
users, and either interpreting options position-dependently or
having separate options may be possible ways to do so. That would
give the end users full flexibility the underlying machinery offers.
I am however not yet convinced that additional complexity at the UI
level that would burden the end users is a reasonable price to pay
for such a flexibility. When was the last time you wanted to grep
for log messages case insensitively for commits authored by Tim but
wanted to hide commits authored by tim when you used the above "log"
command line or similar?
next prev parent reply other threads:[~2015-04-20 17:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-17 10:00 Why does "git log -G<regex>" works with "regexp-ignore-case" but not with other regexp-related options? Tim Friske
2015-04-17 14:26 ` Michael J Gruber
2015-04-17 16:18 ` Junio C Hamano
2015-04-17 17:09 ` Junio C Hamano
2015-04-17 17:45 ` Junio C Hamano
2015-04-20 8:49 ` Michael J Gruber
2015-04-20 17:41 ` Junio C Hamano [this message]
2015-04-20 18:33 ` Linus Torvalds
2015-04-20 18:44 ` Junio C Hamano
2015-04-21 8:41 ` Michael J Gruber
2015-04-21 16:59 ` Junio C Hamano
2015-04-22 9:08 ` Michael J Gruber
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=xmqqbniin1cw.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=me@tifr$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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