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

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

[Konrád Lőrinczi]

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

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

[Sebastian Schuberth]

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

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

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

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

[Konrád Lőrinczi]

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 7/23/2015 9:29, Konrád Lőrinczi wrote:
>
>> Interesting, that git status doesn't show replaced changes, if the
>> mtime is same as original.
>
> 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
>

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

[Johannes Schindelin]

Hi,

On 2015-07-23 09:29, Konrád Lőrinczi wrote:
> 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.

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.

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

[Konstantin Khomoutov]

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

[...]
> 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?

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.

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

[Karsten Blees]

Am 23.07.2015 um 16:53 schrieb Konstantin Khomoutov:
> On Thu, 23 Jul 2015 11:14:11 +0200
> Konrád Lőrinczi <klorinczi@gmail.com> wrote:
> 
> [...]
>> 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?
> 
> 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'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.

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

[Junio C Hamano]

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

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

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.