From: Jonathan Nieder <jrnieder@gmail.com>
Date: Thu, 14 Oct 2010 18:59:45 GMT
Subject: Re: Why is "git tag --contains" so slow?
Message-ID: <20101014185945.GA14634@burratino>
In-Reply-To: <20100705123923.GC21146@sigill.intra.peff.net>

Jeff King wrote:

> This patch doesn't implement auto-detection of skew, but is the program
> I used to calculate, and would provide the basis for such
> auto-detection. It would be interesting to see average skew numbers for
> popular repositories. You can run it as "git skew --all".

Fun.  The story this tells me is that most repositories would benefit
more from special-casing a few commits than from a "[core] clockskew"
setting.

Caveat: the repos mentioned below are not canonical at all.  They are
just some repos I happened to have around, some tracking multiple upstreams.

project # skewed        maximum skew    notes
------- --------        ------------    -----
gtk+    13              13 hrs          worst example seems to be tz related

systemd 3               1 hr            all three come from a single 65min
                                        jump.  Same committer before+after.

dpkg    2               76 days         automatic import from manually
                                        written changelog

glibc   2               31 months       (tag) commits imported to wrong
                                        branches by "git cvsimport", I think

git     4               7 minutes       all four come from a single merge
                                        commit, parents have same committer
                                        as the merge.  probably clock drift
                                        corrected with something like ntp.

guilt   22              96 minutes      from the known (fixed) bug, I assume

linux-2.6 1226          99 days         probably the old guilt bug (e.g., in
                                        ext4, blackfin trees)

sed     0