Jeff King wrote:
> The trick is in keeping track of how far we've gone. It looks like we
> keep the number of seen_commits, increment each time we traverse a
> commit, and then assign that to the "depth" field. But I don't see how
> that can be right. We are traversing in a breadth-first manner, so we
> may look at 1000 commits down one ancestry chain of a merge before
> following the first parent on another.
I haven't really spent more than about 3 minutes on this, but it seems
to use insert_by_date() (except for the start of the search) to walk,
so it would seem to be affected by date skew in some strange way that
I have yet to investigate.
So I merged your git-skew from pu and compiled, and ran
frugalware-current(master u=)$ git skew --all
182448414
frugalware-current(master u=)$ python
[...]
>>> 182448414/86400/365.25
5.7796030116358654
Unless I'm reading your commit message a2ffa6b96 wrong, that means the
repo has a worst-case clock skew of on the order of *six years*... So
maybe it's once again an undocumented effect of clock skew on our
history walks?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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