Re: timestamps not git-cloned

On Fri, 28 Nov 2008, jidanni@jidanni.org wrote:

quoted

quoted

quoted

quoted

quoted

"d" == dhruva  [off-list ref] writes:

d> Also, if you clone from systems across time zones, what time do you
d> expect to set on the files.

I'm just used to tar, cpio, scp -a, rsync -a, ar, etc. using 'date +%s'
seconds internally, so no timezone problem.

I hate it when I get some latest WhizBang.tgz, only to untar it to
find all the files' dates the same, when in fact the README hasn't
been touched in seven years, but you can't tell that from ls -l. I
recall some content tracker was involved.

Well, README was just touched; it wasn't on your disk at all shortly 
before. This would make a big difference if, for example, you unpacked 
"foo-1.0" on top of "foo-1.1" and the timestamps were from when the files 
were originally created, and now all of the source files that changed are 
older than the object files and the build system does nothing.

Of course, with archives, you don't unpack different versions into the 
same directory, but with a version control system, you'll do it all the 
time, so you really need the system to put on disk the times when those 
files were last put there. If you want to know when the README you've got 
is from (and a whole lot more) "git log README" will tell you, although it 
won't tell you if somebody yesterday changed the README they're 
distributing from some other text to a file that's been sitting on their 
disk untouched for seven years.

	-Daniel
*This .sig left intentionally blank*