Re: git describe weird behaviour

[Thomas Rast <trast@student.ethz.ch>]

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