On Thu, Apr 22, 2010 at 10:03:25AM -0500, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Still looking, but definitely some kind of skew problem.
>
> That explains it, then:
>
> $ git log --format=%cd' %h' 19f5fb7 ^v2.6.34-rc1~200
> Sun Jan 24 14:34:07 2010 -0500 19f5fb7
> Mon Dec 7 10:36:20 2009 -0500 d2eecb0
> Fri Jan 1 01:00:21 2010 -0500 f8ec9d6
> Wed Dec 23 07:45:44 2009 -0500 71f2be2
> Fri Jan 22 17:40:42 2010 -0500 1f2acb6
> Mon Feb 15 20:17:55 2010 -0500 15121c1
> Thu Feb 4 23:58:38 2010 -0500 a1de02d
>
> This part of the history is linear.
Thanks for confirming, that was the same stretch of history I ended up
looking at.
> Is the rule that every commit must be at most one day before each of
> its parents? This should probably be documented somewhere, since it
> is possible to override the committer date with GIT_COMMITTER_DATE.
There is no hard and fast rule. We have to deal with _some_ clock skew,
but I think it has been anybody's guess how much. One can always treat
the graph purely topologically (which is what my first patch removing
the cutoff_date check did), but that usually means more computation. In
this case, we go all the way to the roots instead of looking at a
"recent" subgraph. I think we also look at timestamps in rev-list when
linearizing to avoid doing a full topo-sort, but I don't remember what
effects clock skew can have there.
So what should we do with this incident?
1. Declare it too much clock skew and ignore it.
2. Drop the cutoff optimization in favor of correctness. We already do
this for --stdin, as there is no sensible cutoff for multiple
inputs. So you can see how much slower it is:
$ time git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a
a1de02dccf906faba2ee2d99cac56799bda3b96a undefined
real 0m0.163s
user 0m0.140s
sys 0m0.020s
$ time echo a1de02dccf906faba2ee2d99cac56799bda3b96a |
git name-rev --stdin
a1de02dccf906faba2ee2d99cac56799bda3b96a (tags/v2.6.34-rc1~199^2~35)
real 0m3.411s
user 0m3.244s
sys 0m0.164s
So perhaps it is something one would want to enable with a
command-line option. Or even something we could fall back on
automatically as a "slow case" when coming up with an un-nameable
rev.
3. Bump the slop date. 60 days would work here. What's reasonable? A
year? At one year, we are still noticeably slower:
# patched for CUTOFF_SLOP_DATE (365*86400)
$ time git name-rev a1de02dccf906faba2ee2d99cac56799bda3b96a
a1de02dccf906faba2ee2d99cac56799bda3b96a
tags/v2.6.34-rc1~199^2~35
real 0m1.075s
user 0m1.028s
sys 0m0.044s
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html