I use whatchanged!

I just updated to git 2.51 and got the spam about whatchanged being nominated for removal.

I run an important python script that uses this to set file times to the dates of the actual git commits, so as I browse the files I can see their last modified date, and not the date that the file was last synced.

Now, if there is a different way of setting a git repository's files' mod dates to their actual date and time of last commit, please let me know!

The exact usage in the script is:

    git whatchanged --pretty=%at

Thanks!

Dan Allen Idaho Falls, ID

On Wed, Aug 20, 2025, at 21:20, Dan Allen wrote:

According to git-whatchanged(1)

    replace: git whatchanged <opts>
    with:    git log <opts> --raw --no-merges

Should be enough.

Dan Allen <danallen46@gmail.com> writes:

And "git log --raw --pretty=%at" does not fit your need?

Dan Allen <danallen46@gmail.com> writes:

[snip]

Dan,

Would a git-log invocation like this suit your use case?

    git log --raw --no-merges --pretty='%at'

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

Is that close enough to support the functionality of your script?

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

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

Jeff King <peff@peff.net> writes:

"git log" behaviour of showing the presence of empty commits is reasonable in the context of "showing the log". "git whatchanged" bbehaviour of reporting which commits changed things (either in the whole tree, or limited by pathspec) and omitting is reasonable in the context of "showing what commit changed these things".

I do not think byte-for-byte identical output is a requirement, but I of course am biased ;-)

On Fri, Aug 22, 2025, at 15:52, Dan Allen wrote:

That’s great.  Just remember to use reply-all on this list.

Cheers