git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* timestamps not git-cloned
@ 2008-11-28  2:24 jidanni
  2008-11-28  3:08 ` dhruva
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: jidanni @ 2008-11-28  2:24 UTC (permalink / raw)
  To: git

Gentlemen, it's my first git-clone,
$ git-clone git://git.debian.org/git/pkg-fso/files.git
and I'm disappointed to find the timestamps of the files created are
all now and not the date of last edit. At least mention something
about this on the git-clone man page.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-28  2:24 timestamps not git-cloned jidanni
@ 2008-11-28  3:08 ` dhruva
  2008-11-28  5:06   ` jidanni
                     ` (2 more replies)
  2008-11-28 11:51 ` Johannes Schindelin
  2008-11-28 12:58 ` Robin Rosenberg
  2 siblings, 3 replies; 16+ messages in thread
From: dhruva @ 2008-11-28  3:08 UTC (permalink / raw)
  To: jidanni; +Cc: git

Hi,

On Fri, Nov 28, 2008 at 7:54 AM,  <jidanni@jidanni.org> wrote:
> Gentlemen, it's my first git-clone,
> $ git-clone git://git.debian.org/git/pkg-fso/files.git
> and I'm disappointed to find the timestamps of the files created are
> all now and not the date of last edit. At least mention something
> about this on the git-clone man page.

I do not think there is an VCS that records timestamps. Only file
contents are tracked. Also, if you clone from systems across time
zones, what time do you expect to set on the files. IMO, it is not
practical to track timestamps.
 Are you concerned of 'make' doing a complete build when you switch
branches? I guess it makes sense only in that scenario. I wish 'make'
had some feature to track changes instead of timestamps alone...

-dhruva

-- 
Contents reflect my personal views only!

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-28  3:08 ` dhruva
@ 2008-11-28  5:06   ` jidanni
  2008-11-28  6:59     ` Daniel Barkalow
  2008-11-29  8:54     ` Chris Frey
  2008-11-28  5:57   ` David Brown
  2008-11-28 14:59   ` Peter Krefting
  2 siblings, 2 replies; 16+ messages in thread
From: jidanni @ 2008-11-28  5:06 UTC (permalink / raw)
  To: dhruvakm; +Cc: git

>>>>> "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.

Of course I'll allowing you to know my delicate first day impressions.
I'm sure as I grow older I will learn the difference between content
tracker and archiver.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-28  3:08 ` dhruva
  2008-11-28  5:06   ` jidanni
@ 2008-11-28  5:57   ` David Brown
  2008-11-28 14:59   ` Peter Krefting
  2 siblings, 0 replies; 16+ messages in thread
From: David Brown @ 2008-11-28  5:57 UTC (permalink / raw)
  To: dhruva; +Cc: jidanni, git

On Fri, Nov 28, 2008 at 08:38:06AM +0530, dhruva wrote:

>I do not think there is an VCS that records timestamps.

Perforce does, at least optionally.  But, it's model is so different,
I'm not sure it really applies here.  I believe it can either be an
individual file setting, or for a whole workspace.

David

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-28  5:06   ` jidanni
@ 2008-11-28  6:59     ` Daniel Barkalow
  2008-11-29  8:54     ` Chris Frey
  1 sibling, 0 replies; 16+ messages in thread
From: Daniel Barkalow @ 2008-11-28  6:59 UTC (permalink / raw)
  To: jidanni; +Cc: dhruvakm, git

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

> >>>>> "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*

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-28  2:24 timestamps not git-cloned jidanni
  2008-11-28  3:08 ` dhruva
@ 2008-11-28 11:51 ` Johannes Schindelin
  2008-11-28 12:58 ` Robin Rosenberg
  2 siblings, 0 replies; 16+ messages in thread
From: Johannes Schindelin @ 2008-11-28 11:51 UTC (permalink / raw)
  To: jidanni; +Cc: git

Hi,

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

> Gentlemen, it's my first git-clone,
> $ git-clone git://git.debian.org/git/pkg-fso/files.git
> and I'm disappointed to find the timestamps of the files created are
> all now and not the date of last edit.

You are mistaken to be disappointed.  Granted, to a hammer, everything 
looks like a nail.  But it might make more sense to be gentle, and insert 
the syringe by hand.  Maybe it will get less painful that way, too.

In other words, do not be surprised when a source code management tool 
turns out to be lousy at recreating meta-data -- which has as much to do 
with source code than a syringe with a nail.

Hth,
Dscho

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-28  2:24 timestamps not git-cloned jidanni
  2008-11-28  3:08 ` dhruva
  2008-11-28 11:51 ` Johannes Schindelin
@ 2008-11-28 12:58 ` Robin Rosenberg
  2008-11-28 13:20   ` Johannes Schindelin
  2 siblings, 1 reply; 16+ messages in thread
From: Robin Rosenberg @ 2008-11-28 12:58 UTC (permalink / raw)
  To: jidanni; +Cc: git

fredag 28 november 2008 03:24:04 skrev jidanni@jidanni.org:
> Gentlemen, it's my first git-clone,
> $ git-clone git://git.debian.org/git/pkg-fso/files.git
> and I'm disappointed to find the timestamps of the files created are
> all now and not the date of last edit. At least mention something
> about this on the git-clone man page.

I recommend every new Git user to scan the FAQ. It's not just clone,
it's in everything git does in the file system. There is a very good 
reason git behaves this way in general, although clone could be
exception, but then we would have a ton of questions about that
inconsistency.

-- robin

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-28 12:58 ` Robin Rosenberg
@ 2008-11-28 13:20   ` Johannes Schindelin
  0 siblings, 0 replies; 16+ messages in thread
From: Johannes Schindelin @ 2008-11-28 13:20 UTC (permalink / raw)
  To: Robin Rosenberg; +Cc: jidanni, git

Hi,

On Fri, 28 Nov 2008, Robin Rosenberg wrote:

> I recommend every new Git user to scan the FAQ. It's not just clone,
> it's in everything git does in the file system. There is a very good 
> reason git behaves this way in general, although clone could be
> exception, but then we would have a ton of questions about that
> inconsistency.

No, clone cannot be an exception.  The information is just not stored, and 
for a good reason: a file's timestamp is nothing you want to commit in 
source code management.  It just does not make sense at all.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-28  3:08 ` dhruva
  2008-11-28  5:06   ` jidanni
  2008-11-28  5:57   ` David Brown
@ 2008-11-28 14:59   ` Peter Krefting
  2 siblings, 0 replies; 16+ messages in thread
From: Peter Krefting @ 2008-11-28 14:59 UTC (permalink / raw)
  To: dhruva; +Cc: jidanni, Git Mailing List

Hi!

dhruva:

> I do not think there is an VCS that records timestamps. Only file
> contents are tracked.

CVS sort of does. The initial checkout sets the time stamp of files to
their last *check-in* time (and you can import a file with -D to set
its commit time to the current timestamp). Updates do, however, set to
current time (to not break make and friends).

I miss this behaviour in Git, but I have learnt to live with it. I
guess it is like a difference in philosophy on what time-stamps are
supposed to record, like how UNIX "cp" sets the time of the new-born
copy to now, while DOS "copy" sets it to the old time-stamp. Coming
to Unix and Linux from DOS (via OS/2), I find "cp" behaviour weird. But
have learnt to live with it (and use "cp -a" a lot).

-- 
\\// Peter - http://www.softwolves.pp.se/

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-28  5:06   ` jidanni
  2008-11-28  6:59     ` Daniel Barkalow
@ 2008-11-29  8:54     ` Chris Frey
  2008-11-29  9:22       ` Stephen R. van den Berg
  1 sibling, 1 reply; 16+ messages in thread
From: Chris Frey @ 2008-11-29  8:54 UTC (permalink / raw)
  To: jidanni; +Cc: dhruvakm, git

On Fri, Nov 28, 2008 at 01:06:00PM +0800, jidanni@jidanni.org wrote:
> 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.

If this is the important bit, perhaps git-archive could be changed
to create tarballs with file timestamps based on their commit dates.

- Chris

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-29  8:54     ` Chris Frey
@ 2008-11-29  9:22       ` Stephen R. van den Berg
  2008-11-29 10:16         ` Thomas Rast
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen R. van den Berg @ 2008-11-29  9:22 UTC (permalink / raw)
  To: Chris Frey; +Cc: jidanni, dhruvakm, git

Chris Frey wrote:
>On Fri, Nov 28, 2008 at 01:06:00PM +0800, jidanni@jidanni.org wrote:
>> 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.

>If this is the important bit, perhaps git-archive could be changed
>to create tarballs with file timestamps based on their commit dates.

Based on the principle of least surprise, I'd consider this a rather good
idea.
-- 
Sincerely,
           Stephen R. van den Berg.

To people that say "I could care less" - well, why don't you?

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-29  9:22       ` Stephen R. van den Berg
@ 2008-11-29 10:16         ` Thomas Rast
  2008-11-30  0:48           ` jidanni
  2008-11-30  1:14           ` Sitaram Chamarty
  0 siblings, 2 replies; 16+ messages in thread
From: Thomas Rast @ 2008-11-29 10:16 UTC (permalink / raw)
  To: Stephen R. van den Berg; +Cc: Chris Frey, jidanni, dhruvakm, git

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

Stephen R. van den Berg wrote:
> Chris Frey wrote:
> >If this is the important bit, perhaps git-archive could be changed
> >to create tarballs with file timestamps based on their commit dates.
> 
> Based on the principle of least surprise, I'd consider this a rather good
> idea.

Unless I'm missing something, this would make git-archive rather more
expensive than it is now: Tree objects do not record any timestamps,
so figuring out the last commit that changed a file requires a full
history walk in the worst case[*].  (This is another side-effect of
not versioning files.)  On the other hand, current git-archive's
running time depends only on the size of the tree-ish given, including
all subtrees and blobs.

My unscientific guesstimates on how much work this would be, in a
random (old) linux-2.6 clone:

  $ git rev-parse HEAD
  e013e13bf605b9e6b702adffbe2853cfc60e7806
  $ time git ls-tree -r -t $(git rev-list HEAD~5000..HEAD) >/dev/null

  real    0m1.385s
  user    0m1.164s
  sys     0m0.220s
  $ git rev-list HEAD | wc -l
  117812

So reading (and dumping) all those trees and subtrees incurs a penalty
on the order of 30 seconds.  Compare to the current running time of
git-archive:

  $ time git archive --format=tar HEAD >/dev/null

  real    0m2.790s
  user    0m2.684s
  sys     0m0.072s

Of course, the ratio will keep getting worse as history gets longer.

- Thomas

[*] I think to really have a "worst case" here, you need at least one
file in every leaf directory that has not changed since the root
commit, and another that changes in every commit to force the search
to really read every subtree.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch




[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-29 10:16         ` Thomas Rast
@ 2008-11-30  0:48           ` jidanni
  2008-12-01  9:09             ` Andreas Ericsson
  2008-11-30  1:14           ` Sitaram Chamarty
  1 sibling, 1 reply; 16+ messages in thread
From: jidanni @ 2008-11-30  0:48 UTC (permalink / raw)
  To: git

Well all I know is from the simple user who does e.g.,
# aptitude install linux-doc-2.6.26
# ls -lt /usr/share/doc/linux-doc-2.6.26/Documentation/
he thinks "gosh, can't tell what's new vs. what hasn't changed in years".

OK, now I know why this is tolerable upstream: they all use git.

But for the lowly user downstream who gets what git-archive produces,
it seems like a step backwards: "who threw away the timestamp of when
each file was last changed?".

OK, http://git.or.cz/gitwiki/ContentLimitations says this is by design.

And OK, thinking "file by file" is old fashioned, I read. The non-git
end user should just get used to reading ChangeLogs, if any, and stop
doing ls -lt.

But you must admit, /usr/share/doc/linux-doc-2.6.26/Documentation/
etc. are aimed for reading without git.

Anyways, if just in case any individual file modification time
information can still be pried from the 40 byte IDs or whatever, I
would suggest using it by default in git-archive at least, and maybe
even git-clone etc.

Just letting you know my 'valuable first impressions'. I expect once I
start smoking more of this "git" stuff, I too will become comfortably
numb to aforementioned lowly user problem, so you would never know
unless I hereby first told you before it was too late.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-29 10:16         ` Thomas Rast
  2008-11-30  0:48           ` jidanni
@ 2008-11-30  1:14           ` Sitaram Chamarty
  1 sibling, 0 replies; 16+ messages in thread
From: Sitaram Chamarty @ 2008-11-30  1:14 UTC (permalink / raw)
  To: Thomas Rast; +Cc: Stephen R. van den Berg, Chris Frey, jidanni, dhruvakm, git

On Sat, Nov 29, 2008 at 3:46 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Stephen R. van den Berg wrote:
>> Chris Frey wrote:
>> >If this is the important bit, perhaps git-archive could be changed
>> >to create tarballs with file timestamps based on their commit dates.
>>
>> Based on the principle of least surprise, I'd consider this a rather good
>> idea.
>
> Unless I'm missing something, this would make git-archive rather more
> expensive than it is now: Tree objects do not record any timestamps,

How many people use git-archive and how many times a day do they use
it?  For example, kernel.org seems to put out linux-2.x.y.z.tar.bz2
once every 2 to 7 days.

The overhead of this new option (and certainly it should be an option,
not the default) should be measured not against the old running time,
but against the frequency of usage of the tool.  Look at it on those
time scales, it may not be a big deal.

By all accounts, this overhead will not affect the "giterate" [meaning
git-literate ;-)] people too much.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-11-30  0:48           ` jidanni
@ 2008-12-01  9:09             ` Andreas Ericsson
  2008-12-01 11:44               ` Jakub Narebski
  0 siblings, 1 reply; 16+ messages in thread
From: Andreas Ericsson @ 2008-12-01  9:09 UTC (permalink / raw)
  To: jidanni; +Cc: git

jidanni@jidanni.org wrote:
> Well all I know is from the simple user who does e.g.,
> # aptitude install linux-doc-2.6.26
> # ls -lt /usr/share/doc/linux-doc-2.6.26/Documentation/
> he thinks "gosh, can't tell what's new vs. what hasn't changed in years".
> 

They won't be able to do that anyway, since a spelling correction
would update the timestamp anyway. The only way of finding out if
there are *content* changes (which is really what matters) is to
use some sort of history-browser for those documents. Git is good
for that. The sort of people who really need to know when the docs
change can be exptected to have a higher technical knowledge than
the end-users, so it's not too much to ask that they use such a
history browsing tool to find out what's new (or simply "diff").

Either way, timestamps on documents are a very poor way of finding
out when something really changed.

> OK, now I know why this is tolerable upstream: they all use git.
> 
> But for the lowly user downstream who gets what git-archive produces,
> it seems like a step backwards: "who threw away the timestamp of when
> each file was last changed?".
> 
> OK, http://git.or.cz/gitwiki/ContentLimitations says this is by design.
> 
> And OK, thinking "file by file" is old fashioned, I read. The non-git
> end user should just get used to reading ChangeLogs, if any, and stop
> doing ls -lt.
> 
> But you must admit, /usr/share/doc/linux-doc-2.6.26/Documentation/
> etc. are aimed for reading without git.
> 

Well, /usr/bin/less doesn't require git to function, so I fail to see
what the fuzz is all about.

> Anyways, if just in case any individual file modification time
> information can still be pried from the 40 byte IDs or whatever, I
> would suggest using it by default in git-archive at least, and maybe
> even git-clone etc.
> 

It can, but it's a fairly expensive operation, tracking each files
SHA1 backwards in time to see when the commit was done that last made
any changes to it. It's not something you want to do for an archive
containing 26K files. Trust me on this.

> Just letting you know my 'valuable first impressions'. I expect once I
> start smoking more of this "git" stuff, I too will become comfortably
> numb to aforementioned lowly user problem, so you would never know
> unless I hereby first told you before it was too late.


I see a lot of ranting but no patches from you. Since you're the one
with the itch, why not just submit a patch and see if distro packagers
start using it?

Some words of advice though; Make it optional, or it'll be dropped on
the floor. For bonus points, make it calculate timestamps only for a
path-spec delimited set of files. That'll cut down expected runtime
by a *huge* amount for something like the linux kernel.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: timestamps not git-cloned
  2008-12-01  9:09             ` Andreas Ericsson
@ 2008-12-01 11:44               ` Jakub Narebski
  0 siblings, 0 replies; 16+ messages in thread
From: Jakub Narebski @ 2008-12-01 11:44 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: jidanni, git

Andreas Ericsson <ae@op5.se> writes:

> I see a lot of ranting but no patches from you. Since you're the one
> with the itch, why not just submit a patch and see if distro packagers
> start using it?
> 
> Some words of advice though; Make it optional, or it'll be dropped on
> the floor. For bonus points, make it calculate timestamps only for a
> path-spec delimited set of files. That'll cut down expected runtime
> by a *huge* amount for something like the linux kernel.

I think the old idea of 'tree blame' (search archives) would be a good
interface for this feature... if you decide to write it.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2008-12-01 11:45 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-28  2:24 timestamps not git-cloned jidanni
2008-11-28  3:08 ` dhruva
2008-11-28  5:06   ` jidanni
2008-11-28  6:59     ` Daniel Barkalow
2008-11-29  8:54     ` Chris Frey
2008-11-29  9:22       ` Stephen R. van den Berg
2008-11-29 10:16         ` Thomas Rast
2008-11-30  0:48           ` jidanni
2008-12-01  9:09             ` Andreas Ericsson
2008-12-01 11:44               ` Jakub Narebski
2008-11-30  1:14           ` Sitaram Chamarty
2008-11-28  5:57   ` David Brown
2008-11-28 14:59   ` Peter Krefting
2008-11-28 11:51 ` Johannes Schindelin
2008-11-28 12:58 ` Robin Rosenberg
2008-11-28 13:20   ` Johannes Schindelin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).