Git doesn't detect change, if file modification time is restored to original one

I wrote a search & replace perl script, which recursively searches files and replaces text in them. After replace, it restores original modification time (mtime) of file.

Interesting, that git status doesn't show replaced changes, if the mtime is same as original.

Is there a way to force git status to show changes, even if the file dates are the same?

I tried to set core to:
    trustctime = false
    checkStat = minimal
Unfortunately the change is still not detected :(
It seems isn't a way to force fallback to file checking and completely
ignore file modification date :(

Any idea?

Thanks, Konrad Lorinczi

On 7/23/2015 9:29, Konrád Lőrinczi wrote:

See the somewhat related FAQ entry at [1] and also the lengthy discussion at [2] about a similar issue. That said, deleting the .git/index file should make these files appear as modified.

[1] https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F [2] https://github.com/msysgit/git/issues/312

Regards, Sebastian

Based on [1] I found some solutions which makes the changed files appear again as changed: a) touch -m --date=01/01/1980 .git/index So it is a touch, but only a single one, instead of touching all the files in the work dir.

b) git read-tree HEAD Also working well.

I accept these solutions as workarounds, but the real solution would be:
Dev suggestions:
1) Add a --force-reread option to git status, so user can force reread tree.
git status --force-reread

2) Add status.force-reread (true or false) option to .git/config so
user can set this variable permanently for a repo.
status.force-reread = false (should be default)

Could be possible to implement 1) and 2) features to next git release?

Thanks, Konrad Lorinczi

[1] https://github.com/msysgit/git/issues/312

2015-07-23 9:58 GMT+02:00 Sebastian Schuberth <sschuberth@gmail.com>:

On Thu, 23 Jul 2015 11:14:11 +0200 Konrád Lőrinczi <klorinczi@gmail.com> wrote:

[...]

Could you explain what's your real use case with preserving mtimes while changing the files? I mean, implementing "mtime-stability" in your tools appears to be a good excersize in programming but what real-world problem does it solve?

I'm asking because if you are not going to implement the changes to Git you suggested yourself, then someone else should be *convinced* to do so. So far, your trouble appears to be too artifical to bother.

Am 23.07.2015 um 16:53 schrieb Konstantin Khomoutov:

I'd like to add that this is not a git-specific problem: resetting mtime on purpose will fool lots of programs, including backup software, file synchronization tools (rsync, xcopy /D), build systems (make), and web servers / proxies (If-Modified-Since requests).

So you would typically reset mtime if you *want* programs to ignore the changes.

Karsten Blees <karsten.blees@gmail.com> writes:

Yup.  Nicely phrased.

When you run a wholesale rewrite of many files, often you find that some (or many) of the files did not have to be modified. E.g. "perl -i -e 's/old/new/' *" may want to touch all files, but the files that did not have string 'old' in them would have the same contents as before. In such a case, you can avoid unnecessary reinspection of contents (e.g. recompilation) by many tools that pay attention to mtime to see if contents changed by reverting mtime to the original for files that did not change.

Git also pays attention to fields other than mtime, so after

    perl -i -e 's/old/ancient/' *

and reverting mtime even for ones that got changed, we should notice the changes. But you are correct that such an abuse of "touch" will break many other tools.

Hi,

On 2015-07-23 09:29, Konrád Lőrinczi wrote:

Since this is almost identical to https://github.com/msysgit/git/issues/312#issuecomment-124030520 I assume that you wrote that.

In my answer on the (already closed) GitHub ticket, I wrote this:

-- snipsnap --

    I wrote a search & replace perl script, which recursively searches
    files and replaces text in them. After replace, it restores original
    modification time (mtime) of file.

By this "restoring" of the original modification time you broke the contract: the mtime should reflect the time of the latest change. You replaced something, i.e. changed the file contents. Git expects the mtime to be adjusted in that case. By painstakingly faking it back to its original value you essentially told Git: don't worry, this file has not changed since you last saw it.

There is nothing Git can do to outguess you when you go out of your way to break the most fundamental promise of the mtime value.