Reported mtime is not the last modifying commit in the case of merges

[alerque]

I'm the author of git-warp-time, a CLI implemented in Rust that does much the same job as git-restore-mtime. It looks like your project predates mine by quite a while. I remember spending quite a while looking for existing solutions before implementing mine and coming up blank. I probably wouldn't have written anything if I had found this, but here we are. Now that I've been made aware of it I figured I'd put it through some paces and see how it stacks up. I was surprised at how fast it ran, so good work on that front!

That being said I noticed that it was resetting times to quite different values than git warp-time and alternating between that and git restore-mtime was just playing tug of war. It seems like git restore-mtime touches all the files in the repository no matter whether it is necessary or not, but since git warp-time touches and reports on only files that needed changing I would have expected it to settle down to no-changes needed in that direction.

I dug into it a bit and it turns out the commit graph is being processed differently, and git restore-mtime is not taking into account merge commits that affect files in the target branch. It is using the commit time of the last commit in the source branch or merge base rather than the actual merge commit. This results in an incorrect modification time since the merge commit itself actually modifies the file on disk. This is especially relevant when the merge has conflict resolution or the default branch had chronologically newer data than the merge source branch.

Attached is a git repo with such a history as an example that can be extracted with gunzip and then git unbundle: merge-history-example.bundle.gz

You can run each command on the repository then stat test-file to see the different modification dates being set.

I'm not too worried about a solution myself because at this point I'm satisfied with git warp-time and will continue using (and maintaining) it, but I thought it might be useful to report the issue here anyway in case it affects others and you want to fix it.