Good point about time zones differences. There were certainly bias design issues. In our update server, it would take the bias into account to strive for persistency. It seriously helps with tech support when eyeballing file sizes and times with customers. Your right, it would be an option and choice.
What I am doing is finally making the move from CVS since early 2000, which keeps time stamps, with a small effort to migrate to SVN, never completed because it also uses the CreateFile() or fopen() creation time for checking out files. Now I'm catching up with GIT and seeing the same thing. I hope to not it a show stopper until I see what's possible with git. Thanks On Monday, June 5, 2017 at 7:38:23 PM UTC-4, Philip Oakley 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. > > The thing to note is that it is a choice of one particular system, which > has an internal consistency, and sometimes we have to live with that. It > doesn't make it right though. In most cases its never possible to be 100% > right for all the people all of the time. > > ----- Original Message ----- > *From:* winser...@gmail.com <javascript:> > *To:* Git for human beings <javascript:> > *Cc:* philip...@iee.org <javascript:> > *Sent:* Monday, June 05, 2017 11:51 PM > *Subject:* Re: [git-users] Keeping Timestamps > > Hi, Yes, I have seen this "rant" but its nonsense of course. My small > rant. <g> Just because it wasn't added, doesn't mean it was the proper to > keep it out for what many would consider a natural design element for > copying/moving files around. As with most things, it could of been made > optional. Keeping the timestamp(s) is as important as the content itself. > While it ruins build processes, especially complex dependencies, imo, > version control is being used more for documents in general, not just for > source code. Keeping "snapshots" was always a part of the file history. I > personally have source/files all over the network. I am not about to "look" > inside of it to see "differences." Generally, the timestamp itself is > sufficient. > > > Anyway, it would be a welcome "advancement" to GIT to be able to restore > original file commited time stamp(s), at least the last write timestamp, > not necessarily the creation and last read timestamps (Windows). > > If I follow the database layout, the .git stored file time stamps "could" > be used to save the Last Write during a commit and to restore it during a > pull. Otherwise, some other record file/index would be needed. That makes > it more complex. > > Maybe there could be "hooks" during the commit/pull for each file. The > hooks can keep the "extra database." > > -- > HLS > > On Monday, June 5, 2017 at 5:58:14 PM UTC-4, Philip Oakley wrote: >> >> In general, No. It's contrary to the basic Git VCS view. it's the content >> that matters not some 'irrelevant' metadata. >> >> https://confluence.atlassian.com/bbkb/preserving-file-timestamps-with-git-and-mercurial-781386524.html >> >> >> There's a rant by Linus somewhere on that... >> >> >> https://web.archive.org/web/20120518150852/http://kerneltrap.org/mailarchive/git/2007/3/5/240536 >> >> Sorry. >> >> >> ----- Original Message ----- >> *From:* winser...@gmail.com >> *To:* Git for human beings >> *Sent:* Monday, June 05, 2017 10:31 PM >> *Subject:* [git-users] Keeping Timestamps >> >> Hi, Is there an option or version of GIT with a database that keeps the >> last file stamp of committed files?? >> >> -- >> 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+...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> -- 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.
