git whatchanged --i-still-use-this

This is one way I deal with the fact that git has no option to respect mtime.

powershell use-commit-times.ps1

'git whatchanged' is nominated for removal. If you still use this command, please add an extra option, '--i-still-use-this', on the command line and let us know you still use it by sending an e-mail to <mailto:git@vger.kernel.org>.  Thanks. fatal: refusing to run without --i-still-use-this

use-commit-times.ps1:

#use-commit-times
[string[]]$changes = &git whatchanged --reverse --pretty=%at
$mtime = [DateTime]::Now;
[string]$change = $null;
foreach($change in $changes)
{
    if($change.Length -eq 0) { continue; }
    if($change[0] -eq ":")
    {
        $parts = $change.Split("`t");
        $file = $parts[$parts.Length - 1];
        if([System.IO.File]::Exists($file))
        {
            [System.IO.File]::SetLastWriteTimeUtc($file, $mtime);
        }
    }
    else
    {
        $mtime = [DateTimeOffset]::FromUnixTimeSeconds([Int64]::Parse($change)).DateTime;
    }
}

Roy Lomicka Software Developer p: (978) 367-3518 e: mailto:rlomicka@concord.net w: http://www.concord.net/

Concord Technologies and Biscom have come together to better serve you, https://concord.net/concord-technologies-acquires-biscom/.

On Mon, Oct 13, 2025, at 20:55, Roy Lomicka wrote:

The general recommendation is to replace it with `git log` like so:

• Given: `git whatchanged <opts>` • Replace with: `git log <opts> --no-merges --raw`

And I think that should be okay in your case since it seems that commits without changes will not affect the result. See longer explanation below.

-----

Longer explanation:

See:

https://lore.kernel.org/git/83241BDE-1E0D-489A-9181-C608E9FCC17B@gmail.com/

   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.

The recommendation above will give identical output as long as there are no empty commits in the Git history. Where an empty commit is:

• A single-parent commit (git-whatchanged(1) does not care about merges
  by default, and not in your invocation)
• There are no changes compared to the parent (same tree)

See the explanation for why they give different output in this case:

https://lore.kernel.org/git/20250825085428.GA367101@coredump.intra.peff.net/

Normally I wouldn’t note all of that since it seems unlikely to be relevant. (Certainly shouldn’t be relevant for interactive use.) However here the case seems so *scripted* that not being output-equivalent might end up mattering.