git log -L 无差异
git log -L without diff
我正在尝试使用 git log -L <start>,<end>:<filename>，但我希望输出非常有限（实际上只是散列）。虽然 --pretty 以我想要的格式打印提交信息，但我没有找到不显示差异的方法...
例如在 linux-接下来我尝试的是：
git log --pretty=format:"%H" -s -L 70,70:./arch/x86/include/asm/irqflags.h
其中（根据联机帮助页）-s 应该抑制 diff 的输出，但是输出是：
$ git log --pretty=format:"%H" -s -L 70,70:./arch/x86/include/asm/irqflags.h
6abcd98ffafbff81f0bfd7ee1d129e634af13245
diff --git a/include/asm-x86/irqflags.h b/include/asm-x86/irqflags.h
--- a/include/asm-x86/irqflags.h
+++ b/include/asm-x86/irqflags.h
@@ -1,2 +64,1 @@
-#ifdef CONFIG_X86_32
-# include "irqflags_32.h"
+{
96a388de5dc53a8b234b3fd41f3ae2cedc9ffd42
diff --git a/include/asm-x86/irqflags.h b/include/asm-x86/irqflags.h
--- /dev/null
+++ b/include/asm-x86/irqflags.h
@@ -0,0 +1,2 @@
+#ifdef CONFIG_X86_32
+# include "irqflags_32.h"
我正在使用 git 版本 2.10.2
更新：Git 2.22 版及更高版本现在支持将 -L 与 -s 混合使用。参见 。
-L 选项目前（而且显然从来没有）与 -s / --no-patch 兼容，因为 this code called from line_log_print, called from the top of log_tree_commit 当 -L 在影响。所述代码只是从任何匹配的提交中输出整个选定的行范围。 （也许你可以修补 hack 以遵守 diff 输出选项。）
（另一个明显的解决方法是使用 git rev-list 而不是 git log，除了 -L 正如第一个 link 所指出的那样，没有正确地集成到第一名，所以git rev-list不处理。）
一个 grep 解决方案是将输出通过管道传输到 grep 以仅打印与提交匹配的行：
git log -L 10,11:example.txt | grep 'commit \w' -A 4
grep 匹配每个日志条目的第一行，并使用 -A 标志打印接下来的 4 行
虽然有点冗长。很想听听是否有人有更好的解决方案！
Git 2.22（2019 年第 2 季度）会更清楚。
"git log -L<from>,<to>:<path>" 和 "-s" 没有压制补丁
应有的输出。
这已得到纠正。
参见 commit 05314ef (11 Mar 2019), and commit 9f607cd (07 Mar 2019) by Jeff King (peff)。
（由 Junio C Hamano -- gitster -- in commit 31df2c1 合并，2019 年 4 月 9 日）
line-log: detect unsupported formats
If you use "log -L" with an output format like "--raw" or "--stat", we'll silently ignore the format and just output the normal patch.
Let's detect and complain about this, which at least tells the user what's going on.
现在会清楚显示：
-L does not yet support diff formats besides -p and -s
对于 Git 2.25（2020 年第一季度），文档添加了更多内容。
参见 commit 2be4586, commit 2be4586 (26 Dec 2019) by Philippe Blain (phil-blain)。
（由 Junio C Hamano -- gitster -- in commit c4117fc 合并，2020 年 1 月 6 日）
doc: log, gitk: document accepted line-log diff formats
Currently the line-log functionality (git log -L) only supports
displaying patch output (-p | --patch, its default behavior) and suppressing it
(-s | --no-patch).
A check was added in the code to that effect in 05314ef
(line-log: detect unsupported formats, 2019-03-10) but the documentation was not updated.
Explicitly mention:
- that
-L implies -p,
that patch output can be suppressed using -s,
- and that all other diff formats are not allowed.
并且：
The line number, regex or offset parameters and in git log -L <start>,<end>:<file>, or the function name regex in git log -L :<funcname>:<file> must exist in the starting revision, or else the command exits with a fatal error.
因此，除了 You can specify this option more than once，您还有：
Implies --patch.
Patch output can be suppressed using --no-patch, but other diff formats (namely --raw, --numstat, --shortstat, --dirstat, --summary, --name-only, --name-status, --check) are not currently implemented.
使用 Git 2.30（2021 年第一季度），“git log(man)”被记录为不采用路径规范，但这不是由命令行选项解析器强制执行的，它已更正。
参见 commit 39664cb (04 Nov 2020) by Junio C Hamano (gitster)。
（由 Junio C Hamano -- gitster -- in commit f8a1cee 合并，2020 年 11 月 18 日）
log: diagnose -L used with pathspec as an error
Heled-by: Jeff King
The -L option is documented to accept no pathspec, but the command line option parser has allowed the combination without checking so far.
Ensure that there is no pathspec when the -L option is in effect to fix this.
Incidentally, this change fixes another bug in the command line option parser, which has allowed the -L option used together with the --follow option.
Because the latter requires exactly one path given, but the former takes no pathspec, they become mutually incompatible automatically.
Because the -L option follows renames on its own, there is no reason to give --follow at the same time.
The new tests say they may fail with "-L and --follow being incompatible" instead of "-L and pathspec being incompatible".
Currently, the expected failure can come only from the latter, but this is to future-proof them, in case we decide to add code to explicitly die on -L and --follow used together.
我正在尝试使用 git log -L <start>,<end>:<filename>，但我希望输出非常有限（实际上只是散列）。虽然 --pretty 以我想要的格式打印提交信息，但我没有找到不显示差异的方法...
例如在 linux-接下来我尝试的是：
git log --pretty=format:"%H" -s -L 70,70:./arch/x86/include/asm/irqflags.h
其中（根据联机帮助页）-s 应该抑制 diff 的输出，但是输出是：
$ git log --pretty=format:"%H" -s -L 70,70:./arch/x86/include/asm/irqflags.h
6abcd98ffafbff81f0bfd7ee1d129e634af13245
diff --git a/include/asm-x86/irqflags.h b/include/asm-x86/irqflags.h
--- a/include/asm-x86/irqflags.h
+++ b/include/asm-x86/irqflags.h
@@ -1,2 +64,1 @@
-#ifdef CONFIG_X86_32
-# include "irqflags_32.h"
+{
96a388de5dc53a8b234b3fd41f3ae2cedc9ffd42
diff --git a/include/asm-x86/irqflags.h b/include/asm-x86/irqflags.h
--- /dev/null
+++ b/include/asm-x86/irqflags.h
@@ -0,0 +1,2 @@
+#ifdef CONFIG_X86_32
+# include "irqflags_32.h"
我正在使用 git 版本 2.10.2
更新：Git 2.22 版及更高版本现在支持将 -L 与 -s 混合使用。参见
-L 选项目前（而且显然从来没有）与 -s / --no-patch 兼容，因为 this code called from line_log_print, called from the top of log_tree_commit 当 -L 在影响。所述代码只是从任何匹配的提交中输出整个选定的行范围。 （也许你可以修补 hack 以遵守 diff 输出选项。）
（另一个明显的解决方法是使用 git rev-list 而不是 git log，除了 -L 正如第一个 link 所指出的那样，没有正确地集成到第一名，所以git rev-list不处理。）
一个 grep 解决方案是将输出通过管道传输到 grep 以仅打印与提交匹配的行：
git log -L 10,11:example.txt | grep 'commit \w' -A 4
grep 匹配每个日志条目的第一行，并使用 -A 标志打印接下来的 4 行
虽然有点冗长。很想听听是否有人有更好的解决方案！
Git 2.22（2019 年第 2 季度）会更清楚。
"git log -L<from>,<to>:<path>" 和 "-s" 没有压制补丁
应有的输出。
这已得到纠正。
参见 commit 05314ef (11 Mar 2019), and commit 9f607cd (07 Mar 2019) by Jeff King (peff)。
（由 Junio C Hamano -- gitster -- in commit 31df2c1 合并，2019 年 4 月 9 日）
line-log: detect unsupported formats
If you use "
log -L" with an output format like "--raw" or "--stat", we'll silently ignore the format and just output the normal patch.
Let's detect and complain about this, which at least tells the user what's going on.
现在会清楚显示：
-L does not yet support diff formats besides -p and -s
对于 Git 2.25（2020 年第一季度），文档添加了更多内容。
参见 commit 2be4586, commit 2be4586 (26 Dec 2019) by Philippe Blain (phil-blain)。
（由 Junio C Hamano -- gitster -- in commit c4117fc 合并，2020 年 1 月 6 日）
doc:
log,gitk: document accepted line-log diff formats
Currently the line-log functionality (
git log -L) only supports displaying patch output (-p | --patch, its default behavior) and suppressing it (-s | --no-patch).
A check was added in the code to that effect in 05314ef (line-log: detect unsupported formats, 2019-03-10) but the documentation was not updated.Explicitly mention:
- that
-Limplies-p, that patch output can be suppressed using-s,- and that all other diff formats are not allowed.
并且：
The line number, regex or offset parameters and in
git log -L <start>,<end>:<file>, or the function name regex ingit log -L :<funcname>:<file>must exist in the starting revision, or else the command exits with a fatal error.
因此，除了 You can specify this option more than once，您还有：
Implies
--patch.
Patch output can be suppressed using--no-patch, but other diff formats (namely--raw,--numstat,--shortstat,--dirstat,--summary,--name-only,--name-status,--check) are not currently implemented.
使用 Git 2.30（2021 年第一季度），“git log(man)”被记录为不采用路径规范，但这不是由命令行选项解析器强制执行的，它已更正。
参见 commit 39664cb (04 Nov 2020) by Junio C Hamano (gitster)。
（由 Junio C Hamano -- gitster -- in commit f8a1cee 合并，2020 年 11 月 18 日）
log: diagnose-Lused with pathspec as an errorHeled-by: Jeff King
The
-Loption is documented to accept no pathspec, but the command line option parser has allowed the combination without checking so far.
Ensure that there is no pathspec when the-Loption is in effect to fix this.Incidentally, this change fixes another bug in the command line option parser, which has allowed the
-Loption used together with the--followoption.
Because the latter requires exactly one path given, but the former takes no pathspec, they become mutually incompatible automatically.
Because the-Loption follows renames on its own, there is no reason to give--followat the same time.The new tests say they may fail with "
-Land--followbeing incompatible" instead of "-Land pathspec being incompatible". Currently, the expected failure can come only from the latter, but this is to future-proof them, in case we decide to add code to explicitly die on-Land--followused together.