On 2017-06-05, at 4:39 PM, Philip Oakley <philipoak...@iee.org> wrote:
> Hi, yes it can be awkward when different systems make different choices about > which feature they want to use as the indicator for what they really want to > look at. For git the sha1 object id (oid) is what tells you that it has > changed. Its unfortunate that the 'timestamp' concept is used elsewhere as it > doesn't really scale in a distributed architecture. My local time may be > different to yours, so if I restore a file that you saved then what should > happend to the time stamp. Should it be adjusted for time zone, for clock > drift, etc. Your stored file may be in the future relative to my system clock > which causes some systems to 'explode', etc. Easy. Convert your local time to UTC; store the UTC time. Clocks not set correctly? Fine, record the system inaccurate time. If your clock is not set right, there's bigger things to worry about than getting git to learn about inaccurate clocks :-). ... Commits record the timestamp of the commit, right? So git already knows how to work with UTC times. A "check-in" (add operation) doesn't record a time anywhere, *except the timestamp of the object in the git database*. So there is a time thingy in there, to be retro-collected. Except, you know, once it goes into a pack file. So ... I think it makes good sense for git to record timestamps as of the time of "add" -- it is already recorded in the file meta data for the object, and it can be saved when copied into a pack file. Whether or not it makes sense to restore it when you check a file out is another thing, and that would be use-case dependent (as mentioned, for a compile environment, you want to force updates; for a data environment, you probably want the time of the data to be accurate.) Now, for data that has lost the "timestamp", is in a pack file, with no recorded pack file? How about defaulting to the time of the earliest commit that the file appears in? --- Entertaining minecraft videos http://YouTube.com/keybounce -- 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.
