On 2017-06-06, at 7:31 PM, Maurizio Vitale <mrz....@gmail.com> wrote:
> Everybody else manage without restoring the timestamps, so it would be > probably easier if you described what you want to achieve. Here's the problem: Just because people "manage" without a feature doesn't mean the feature is wanted. Heck, people managed without DVCS's/git for a while :-). > Because when you clone a repository clearly the time of the last write is > when the files are written into your workspace. Pretending that is some other > date in the past has a usefulness that I fail to see. > Furthermore, do you really want to believe that a file is newer than it is > just because somebody (human or script) run touch (or similar)? So you want use cases? Alright. I routinely use the modified time of files (sadly, the only filetime I can rely on) to sort, to place a file in historical context, etc. I'm on a system that has at least the following sets of times: 1. Unix C-time, when the inode was modified. But inodes are not the native file designation here. 2. Unix M-time, when the file was last modified. Except when it is not because not all file writes update this for some reason. 3. Unix A-time, which is useless most of the time because it is not updated, or because a system indexer reads everything anyways. 4. Hfs+ created, added-to-directory, modified, and last opened, which are not the same as the unix ones and are set by a number of things used in the real file system and not propagated out to the unix/posix system. Oh yea -- "last opened" isn't even set by posix things because they aren't real "apps". Of these, Mtime is the most reliable. But ... well, it turns out that a memory-mapped file that is "written" to doesn't update mtime. [How significant was this? It broke ntp, because Apple set up a new system with "pacemaker", so that ntp would do less work, and give significant battery savings (pacemaker would only have to adjust things twice a second, I think was the default).] Use cases? Relying on the time stamp to know the age of the file. Backup programs -- the good ones -- restore the timestamps of the files. Restoring a file out of a git archive is very similar to restoring a file from the backup. --- Yes, for files that are being used for compilation, where you want the new file to be compiled, you want "now" so that things will be read and processed. But if you are looking at non-source data, "time" can matter. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
