Strange behavior of "git log" with file argument

Vincent LefevreJun 19, 2026, 15:44 UTC on lore

With 2.53.0 under Debian/unstable:

* https://github.com/git/git.git repository
  at 95e20213faefeb95df29277c58ac1980ab68f701

"git log git-gui/git-gui--askyesno.sh" outputs nothing. To get logs, I can add the -m option. In particular, this shows 3 non-merge commits.

So the behavior without -m seems incorrect, and at least unhelpful.

* https://gitlab.inria.fr/mpfr/mpfr.git repository
  at 74cb29f0908c2887dc8c3e6ba7a3c5a2f20710a3

"git log --reverse AUTHORS" shows only 2 commits:

  bfa9d064e1cf7a736740c73b9773eabb11da6ed7
  5a9521d1f305268e575c4a5c4de13614acef6321

where bfa9d064e1cf7a736740c73b9773eabb11da6ed7 corresponds to the file creation and 5a9521d1f305268e575c4a5c4de13614acef6321 is unrelated to the AUTHORS file:

  git show 5a9521d1f305268e575c4a5c4de13614acef6321

contains nothing about AUTHORS, and "git log AUTHORS" does not list this commit. But "git log AUTHORS" also lists

  b28347ab59db2a99168a17c3e1804000069199aa

which had been done *before* the AUTHORS file was created!

Note: According to the git-log(1) man page, the --reverse option
is supposed to affect only the order, not the list of commits to
be shown:

  --reverse
      Output the commits chosen to be shown (see Commit Limiting section
      above) in reverse order. Cannot be combined with --walk-reflogs.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Junio C HamanoJun 19, 2026, 17:02 UTC in reply to Vincent Lefevre on lore

Re: Strange behavior of "git log" with file argument

Vincent Lefevre <vincent@vinc17.net> writes:

> "git log git-gui/git-gui--askyesno.sh" outputs nothing. To get logs, I
> can add the -m option. In particular, this shows 3 non-merge commits.

This is a known joy of subtree-merge hack.

You could probably do

    $ git log -- git-gui/git-gui--askyesno.sh git-gui--askyesno.sh

The thing is, in git-gui project, git-gui--askyesno.sh script is at the root level of its working tree, and we are subtree-merging it in a subdirectory. Once the history traversal realizes that a change to the script came from git-gui history, it would need to be told that it needs to pay attention to git-gui--askyesno.sh at the root tree as well.