Re: Why is "git tag --contains" so slow?
- From
Clemens Buchacher <drizzd@aon.at>
- Date
- Oct 28, 2010, 08:07 UTC
- Message-ID
- <20101028080739.GA3953@localhost>
- In-Reply-To
- <20101027171145.GA6921@sigill.intra.peff.net>
Hi Jeff,
On Wed, Oct 27, 2010 at 10:11:45AM -0700, Jeff King wrote:
Show 5 quoted lines
> > Thanks both of you for the extra data points. If you don't mind, would > you consider running my updated git-skew below on your test cases (or > tweaking your skew detectors, since you both seem to be getting a '# > skewed' column that mine didn't output).
I think this works well for small skews and for positive skews, i.e., if the date goes back to the future. But if the date goes into the past, that time is used as the new reference, and all subsequently traversed commits are considered skewed. So for example, if I add the following commit to git.git's current master, the longest run becomes 1092 commits.
$ GIT_COMMITTER_DATE=$(date -d "now-1 year") git commit --allow-empty -m add-skew
To solve this, we could keep track of a window of the last n commits traversed and take as a new time reference the largest date within that window which is smaller than the previous reference. That way we would fail to detect skew only if all of the commits in that window are skewed into the past or into the future.
This particular scenario does not seem to occur in any of the repos I tested, except maybe for the mesa repo. But manual inspection shows that that repo has very long runs of skewed commits anyways.
linux 99 days 80
wine 1 14 days 1
mesa 4930 150 days 1520
xf86-video-ati 13 ~2.5 hrs 4
xf86-video-intel 26 8 hrs 4
xf86-video-nouveau 12 10 hrs 9
fluxbox 0 0 0
metacity 0 0 0
openbox 8 4 hrs 4
giggle 2 21 min 2
glibc 2 931 days 1Clemens