Everybody else manage without restoring the timestamps, so it would be probably easier if you described what you want to achieve.
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)? The only use case you mention is: 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. If you're relying on timestamps to decide whether two files from all over the network are the same or not, you're in for a world of sorrow. You say "I'm not about to look inside to see the differences". Nobody does that. 'diff -w F1 F2' would tell you if the file differs, reliably. Cryptographic hashes would achieve the same. Timestamps wouldn't. 'diff F1 F2|wc -l' would give you an idea of how different. [if the files are binaries, you probably need something a bit smarter than diff, but the concepts still holds] Sure diff doesn't tell you which file is newer, but neither do timestamps. So you're asking the git developers to add code for something that cannot be made to work in any meaningful way and would only help a minute minority of people, if any (certainly not for deciding if two files are the same, and I haven't seen other uses described in this thread) On Mon, Jun 5, 2017 at 6:51 PM, <winserver2...@gmail.com> wrote: > 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-timest >> amps-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. > -- 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.
