Re: timestamps not git-cloned

[Thomas Rast <trast@student.ethz.ch>]

[-- 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 --]