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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Karsten Blees <karsten.blees@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]