Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html