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: winserver2...@gmail.com
To: Git for human beings
Cc: philipoak...@iee.org
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.
