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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
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 : > 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 > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
On Thu, 23 Jul 2015 11:14:11 +0200 Konrád Lőrinczi 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
Am 23.07.2015 um 16:53 schrieb Konstantin Khomoutov: > On Thu, 23 Jul 2015 11:14:11 +0200 > Konrád Lőrinczi 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
Karsten Blees 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
