git log - git log -L without diff

Question

I'm trying to use git log -L <start>,<end>:<filename> but I would like to have very limited output (actually just hashes). While --pretty prints the commit info in the format I want, I did not find a way to not display the diff...

e.g. on linux-next what I tried is:

git log --pretty=format:"%H" -s -L 70,70:./arch/x86/include/asm/irqflags.h

where (according to the manpage) the -s is supposed to Supress the ouput of the diff, however the output is:

$ 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"

I am using git version 2.10.2

Answer 1

That will be clearer with Git 2.22 (Q2 2019).

"git log -L<from>,<to>:<path>" with "-s" did not suppress the patch output as it should.
This has been corrected.

See commit 05314ef (11 Mar 2019), and commit 9f607cd (07 Mar 2019) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 31df2c1, 09 Apr 2019)}

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.

It will now clearly display:

-L does not yet support diff formats besides -p and -s

---

With Git 2.25 (Q1 2020), the documentation adds more.

See commit 2be4586, commit 2be4586 (26 Dec 2019) by Philippe Blain (phil-blain).
^{(Merged by Junio C Hamano -- gitster -- in commit c4117fc, 06 Jan 2020)}

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.

And:

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.

So, in addition of You can specify this option more than once, you have:

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.

---

With Git 2.30 (Q1 2021), "git log^(man)" is documented to take no pathspec, but this was not enforced by the command line option parser, which has been corrected.

See commit 39664cb (04 Nov 2020) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit f8a1cee, 18 Nov 2020)}

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.