I use whatchanged!

I use whatchanged!

[Dan Allen]

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

Re: I use whatchanged!

[Kristoffer Haugsbakk]

On Wed, Aug 20, 2025, at 21:20, Dan Allen wrote:
> 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

According to git-whatchanged(1)

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

Should be enough.

-- 
semantic drift

Re: I use whatchanged!

[Kristoffer Haugsbakk]

On Fri, Aug 22, 2025, at 15:52, Dan Allen wrote:
>> On 20 Aug 2025, at 14:46, Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote:
>>[snip]
>> According to git-whatchanged(1)
>>
>>    replace: git whatchanged <opts>
>>    with:    git log <opts> --raw --no-merges
>>
>> Should be enough.
>>
>> --
>> semantic drift
>
> That works!  Thank you.

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

Cheers

-- 
Kristoffer

Re: I use whatchanged!

[Junio C Hamano]

Dan Allen <danallen46@gmail.com> writes:

> The exact usage in the script is:
>
>     git whatchanged --pretty=%at

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

Re: I use whatchanged!

[Ben Zanin]

Dan Allen <danallen46@gmail.com> writes:
> 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
[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?

-- 
	Ben

Re: I use whatchanged!

[Jeff King]

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

Re: I use whatchanged!

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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.

"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 ;-)