On Wed, Aug 20, 2025 at 04:57:43PM -0400, Ben Zanin wrote:

When I test that by running it inside a working directory of the git
repo as of commit c44beea485f0f2feaf460e2ac87fdd5608d63cf0 / v2.51.0, it
looks like the output of `git whatchanged --pretty='%at'` and that of
`git log --raw --no-merges --pretty='%at'` is almost identical but for
the addition of a couple of extra timestamps in the output:

    diff -U0 \
      <(git whatchanged --i-still-use-this --pretty='%at') \
      <(git log --raw --no-merges --pretty='%at')

...gives me..:

    --- /dev/fd/63  2025-08-20 16:55:36.936065126 -0400
    +++ /dev/fd/62  2025-08-20 16:55:36.936065126 -0400
    @@ -39,0 +40 @@
    +1754972997
    @@ -3773,0 +3775 @@
    +1745540054
    @@ -18102,0 +18105 @@
    +1717188675
    @@ -210119,0 +210123 @@
    +1179951046
    @@ -243728,0 +243733 @@
    +1113865892

Looks like those are cases where the commit is empty (it's not a merge,
and has the same tree as its first parent). E.g.:

  $ commits=8d2709d075d65ba386a4dac157129ef868c283e5^-
  $ git log --oneline --raw --no-merges $commits
  8d2709d075 A few hotfixes before -rc2

  $ git whatchanged --i-still-use-this $commits
  [no output]

The culprit is the revs.always_show_header flag, which git-log sets but
git-whatchanged does not. I don't think there is a way to influence it
with an option, though. You can simplify history by giving a pathspec,
but that can have broader changes (e.g., it may also simplify away side
branches).

I don't know if that's an option that should be added before declaring
whatchanged dead. Arguably the git-log behavior is much more reasonable,
but I don't know if anybody cares about being byte-for-byte identical to
whatchanged behavior.

-Peff