Re: Why is "git tag --contains" so slow?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 14, 2010, 18:59 UTC
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