Hi,
I am in the process of rewriting the core logic of git blame (the
current speed of which is quite an impediment to some workflows).
I currently have one question I don't see an answer to right away, and
that question arises in doing a reasonably robust traversal of commits
without determining topology first:
The question is what guarantees I have with regard to the commit date of
a commit in relation to that of its parent commits:
a) none
b) commitdate(child) >= commitdate(parent)
c) commitdate(child) > commitdate(parent)
Obviously, I can rely on c) being true "almost always": it's definitely
good for a heuristic used for improving performance (meaning as an
ordering criterion for a commit priority queue). The problem is how
much I should cater for graceful behavior for the cases where it's not.
Does git do any actual checks before pushing?
--
David Kastrup
On Wed, Jan 15, 2014 at 11:37:08AM +0100, David Kastrup wrote:
The question is what guarantees I have with regard to the commit date of
a commit in relation to that of its parent commits:
a) none
b) commitdate(child) >= commitdate(parent)
c) commitdate(child) > commitdate(parent)
a) none
Obviously, I can rely on c) being true "almost always":
Actually, b) is quite often the case in automated processes (e.g., "git
am" or "git rebase"). The author dates are different, but the committer
dates may be in the same second.
And of course a) is the result of clock skew and software bugs.
it's definitely
good for a heuristic used for improving performance (meaning as an
ordering criterion for a commit priority queue). The problem is how
much I should cater for graceful behavior for the cases where it's not.
Yes, this is exactly how git uses it. We generally walk breadth-first
through the graph, relying on commit times for performance but not
correctness.
There are some parts of the code that will behave badly with clock skew.
For example, "--since" will stop traversing when we hit a certain point.
It requires a fixed number of "too old" commits before quitting, though,
in an attempt to bypass small runs of skewed clocks.
The "git describe --contains" algorithm will also produce wrong results
in the face of skew. I believe it uses a "slop" of 24 hours in its skew.
The current "tag --contains" algorithm is currently correct in the face
of skew, but it can go much faster if you accept that skew will cause it
to go wrong. I suspect there are other algorithms that could be sped up,
too, if we had trustworthy generation numbers (I implemented and timed
the "--contains" algorithm, but haven't done so for other algorithms).
I've played with calculating and caching the generation numbers at
repack time, but there aren't any patches currently under consideration.
Does git do any actual checks before pushing?
No. One problem with checking the commit relationships is that it may
not be the new commit which is broken (by skewing backwards), but rather
the commit it builds on (which has skewed forwards). If you are building
on such a fast-forward commit, it is often to late to fix that commit.
So you have to fast-forward yourself, propagating the bogus value.
If the receiving machine checked the incoming commits against its own
internal clock, that could work. You would still want to check the
commit relationships to catch new commits that erroneously claim to be
from the past, though (that is, before their parents).
-Peff
Jeff King [off-list ref] writes:
There are some parts of the code that will behave badly with clock skew.
For example, "--since" will stop traversing when we hit a certain point.
It requires a fixed number of "too old" commits before quitting, though,
in an attempt to bypass small runs of skewed clocks.
That actually turns out to be a somewhat sore point for me: I use
something like
git shortlog -n --since 2013/12/01 --until 2014/01/01 master
for generating statistics on LilyPond when I am doing my monthly report
begging the community for money.
It turns out that the numbers of commits attributed to me tend to go
_down_ quite regularly in the time from starting the report to sending
it out. Which might also cause me to overlook a particularly
selfpraiseworthy item.
Not sure how feasible it would be to arrive at a stable and
complementary set of --since/--until.
--
David Kastrup
On Wed, Jan 15, 2014 at 06:13:30AM -0500, Jeff King wrote:
On Wed, Jan 15, 2014 at 11:37:08AM +0100, David Kastrup wrote:
quoted
The question is what guarantees I have with regard to the commit date of
a commit in relation to that of its parent commits:
a) none
b) commitdate(child) >= commitdate(parent)
c) commitdate(child) > commitdate(parent)
a) none
quoted
Obviously, I can rely on c) being true "almost always":
Actually, b) is quite often the case in automated processes (e.g., "git
am" or "git rebase"). The author dates are different, but the committer
dates may be in the same second.
And of course a) is the result of clock skew and software bugs.
... or importing non-git repositories that don't have commit info
separated from author info like git does. In such cases, it's usual to
duplicate the author info as commit info so that clones of the same
non-git repo end up with the same git sha1s. Mercurial easily allows
author dates to be in a non topological order.
Mike