git - 如何反转 `git log --grep=` 或如何显示与模式不匹配的 git 日志

Question

我想使用 git log 来显示所有不匹配给定模式的提交。我知道我可以使用以下内容来显示所有与模式匹配的提交:

git log --grep=<pattern>

如何反转匹配的意义？

我正在尝试忽略消息中“跳到版本...”的提交。

编辑:我希望我的最终输出非常冗长。例如git 日志 --pretty --stat。所以 git log --format=oneline 的输出对我不起作用。

Answer 1

这将通过 Git 2.4+ (Q2 2015) 成为可能:见commit 22dfa8a通过 Christoph Junghans ( junghans ) :

log: teach --invert-grep option

"git log --grep=<string>" shows only commits with messages that match the given string, but sometimes it is useful to be able to show only commits that do not have certain messages (e.g. "show me ones that are not FIXUP commits").

Originally, we had the invert-grep flag in grep_opt, but because "git grep --invert-grep" does not make sense except in conjunction with "--files-with-matches", which is already covered by "--files-without-matches", it was moved it to revisions structure.
To have the flag there expresses the function to the feature better.

When the newly inserted two tests run, the history would have commits with messages "initial", "second", "third", "fourth", "fifth", "sixth"and "Second", committed in this order.
The commits that does not match either "th" or "Sec" is "second" and "initial". For the case insensitive case only "initial" matches.

--invert-grep

Limit the commits output to ones with log message that do not match the pattern specified with --grep=<pattern>.

例子:

我首先在其中使用“sequencer”grep 消息:

vonc@voncm C:\Users\vonc\prog\git\git

> git log -2 --pretty="tformat:%s" --grep=sequencer
Merge branch 'js/sequencer-wo-die'
sequencer: ensure to release the lock when we could not read the index

如果我想要带有无排序器的消息:

> git log -2 --pretty="tformat:%s" --grep=sequencer --invert-grep
Second batch for 2.11
Merge branch 'js/git-gui-commit-gpgsign'

---

警告:这只会反转 --grep 指定的模式.
它将不再反转标题匹配项，例如 --author , --committer ，开始 Git 2.35+(2022 年第一季度)。
请参阅“equivalence of: git log --exclude-author? ”中的示例。

---

请注意 git -P log -1 --invert-grep可能出现段错误:

将“--invert-grep”和“--all-match”而不是“--grep”提供给“ git log ”^{( man)} 命令导致尝试访问 grep 模式表达式尚未分配的结构，已使用 Git 2.39(2022 年第 4 季度)更正。

参见 commit db84376 (2022 年 10 月 11 日)Ævar Arnfjörð Bjarmason ( avar ) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit 91d3d7e，2022 年 10 月 21 日)}

grep.c: remove "extended" in favor of "pattern_expression", fix segfault

^{Reported-by: orygaw
Signed-off-by: Ævar Arnfjörð Bjarmason}

Since 79d3696 ("git-grep: boolean expression on pattern matching.", 2006-06-30, Git v1.4.2-rc1 -- merge) the "pattern_expression" member has been used for complex queries (AND/OR...), with "pattern_list" being used for the simple OR queries.
Since then we've used both "pattern_expression" and its associated boolean "extended" member to see if we have a complex expression.

Since f41fb66 (revisions API: have release_revisions() release , 2022-04-13, Git v2.37.0-rc0 -- merge listed in batch #8) (revisions API: have release_revisions() release "grep_filter", 2022-04-13) we've had a subtle bug relating to that: If we supplied options that were only used for "complex queries", but didn't supply the query itself we'd set "opt->extended", but would have a NULL "pattern_expression".
As a result these would segfault as we tried to call "free_grep_patterns()" from "release_revisions()":

git -P log -1 --invert-grep
git -P log -1 --all-match

The root cause of this is that we were conflating the state management we needed in "compile_grep_patterns()" itself with whether or not we had an "opt->pattern_expression" later on.

In this cases as we're going through "compile_grep_patterns()" we have no "opt->pattern_list" but have "opt->no_body_match" or "opt->all_match".
So we'd set "opt->extended = 1", but not "return" on "opt->extended" as that's an "else if" in the same "if" statement.

That behavior is intentional and required, as the common case is that we have an "opt->pattern_list" that we're about to parse into the "opt->pattern_expression".

But we don't need to keep track of this "extended" flag beyond the state management in compile_grep_patterns() itself.
It needs it, but once we're out of that function we can rely on "opt->pattern_expression" being non-NULL instead for using these extended patterns.