git log -G / git log -S for jj log

[9999years]

Git contains a number of flags on git log for grepping diffs and commit messages (listed below). Today, jj supports some of this functionality with the diff_contains(string_pattern, [fileset pattern]), description(string_pattern), and subject(string_pattern) revset functions. However, Git's tooling here provides a few advantages:

1. The possible queries are richer than "the diff contains this pattern"; for example with -S you can search only for commits that change the number of occurrences of a pattern, letting users filter out diffs that simply move code around.
2. Less shell escaping is required. jj log -r '::@ & diff_contains(regex:"foo")' is pretty clumsy compared to git log -G foo.

To be clear, the revset language is (IMO) one of jj's best features, and I'm not suggesting we build features that don't leverage it. These features should be available in the revset language first, but I think there's a lot of value in having dedicated command-line flags for common use-cases.

Questions for discussion:

• Do you miss these flags / want them in jj?
• Is there a way we can make revsets friendlier for use-cases like this? The punctuation overhead is pretty rough right now; I typically want to run a bunch of git log -G queries in a row (until I find the commit I'm looking for), and the revset language means I can't just change the last word or argument of the previous invocation.

Flags

Here are the flags mentioned in man git-log. I mostly miss -G and -S (and occasionally --grep).

-S<string>

Look for differences that change the number of occurrences of the specified <string> (i.e.
addition/deletion) in a file. Intended for the scripter’s use.

It is useful when you’re looking for an exact block of code (like a struct), and want to know the history of
that block since it first came into being: use the feature iteratively to feed the interesting block in the
preimage back into -S, and keep going until you get the very first version of the block.

Binary files are searched as well.

-G<regex>

Look for differences whose patch text contains added/removed lines that match <regex>.

To illustrate the difference between -S<regex> --pickaxe-regex and -G<regex>, consider a commit with the
following diff in the same file:

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

While git log -G"frotz\(nitfol" will show this commit, git log -S"frotz\(nitfol" --pickaxe-regex will not
(because the number of occurrences of that string did not change).

Unless --text is supplied patches of binary files without a textconv filter will be ignored.

See the pickaxe entry in gitdiffcore(7) for more information.

--pickaxe-all

When -S or -G finds a change, show all the changes in that changeset, not just the files that contain the
change in <string>.

--pickaxe-regex

Treat the <string> given to -S as an extended POSIX regular expression to match.

--grep=<pattern>

Limit the commits output to ones with a log message that matches the specified pattern (regular expression).
With more than one --grep=<pattern>, commits whose message matches any of the given patterns are chosen (but
see --all-match).

When --notes is in effect, the message from the notes is matched as if it were part of the log message.

[joyously]

aside: there is a PR for adding -G to mean --no-graph

[PhilipMetzger]

See #6477 and #7595 for improving the state here.