Re: timestamps not git-cloned

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Nov 28, 2008, 06:59 UTC
Message-ID: <alpine.LNX.1.00.0811280058230.19665@iabervon.org>
In-Reply-To: <87tz9sv3rb.fsf@jidanni.org>

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

Show 12 quoted lines

> >>>>> "d" == dhruva  <dhruvakm@gmail.com> 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*