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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 23, 2015, 17:32 UTC
Message-ID: <xmqqsi8epyog.fsf@gitster.dls.corp.google.com>
In-Reply-To: <55B1053D.7030006@gmail.com>

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

Show 7 quoted lines

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