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
