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 

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

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.

Reply via email to