summaryrefslogtreecommitdiff
path: root/t/t6009-rev-list-parent.sh
AgeCommit message (Collapse)AuthorFilesLines
2008-03-19Make revision limiting more robust against occasional bad commit datesLibravatar Linus Torvalds1-1/+1
The revision limiter uses the commit date to decide when it has seen enough commits to finalize the revision list, but that can get confused if there are incorrect dates far in the past on some commits. This makes the logic a bit more robust by - we always walk an extra SLOP commits from the source list even if we decide that the source list is probably all done (unless the source is entirely empty, of course, because then we really can't do anything at all) - we keep track of the date of the last commit we added to the destination list (this will *generally* be the oldest entry we've seen so far) - we compare that with the youngest entry (the first one) of the source list, and if the destination is older than the source, we know we want to look at the source. which causes occasional date mishaps to be handled cleanly. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-13add test_cmp function for test scriptsLibravatar Jeff King1-1/+1
Many scripts compare actual and expected output using "diff -u". This is nicer than "cmp" because the output shows how the two differ. However, not all versions of diff understand -u, leading to unnecessary test failure. This adds a test_cmp function to the test scripts and switches all "diff -u" invocations to use it. The function uses the contents of "$GIT_TEST_CMP" to compare its arguments; the default is "diff -u". On systems with a less-capable diff, you can do: GIT_TEST_CMP=cmp make test Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-03known breakage: revision range computation with clock skewLibravatar Junio C Hamano1-0/+38
This is the absolute minimum (and reliable) reproduction recipe to demonstrate that revision range in a history with clock skew sometimes fails to mark UNINTERESTING commit in topologically early parts of the history. The history looks like this: o---o---o---o one four but one has the largest timestamp. "git rev-list four..one" fails to notice that "one" should not be emitted. Signed-off-by: Junio C Hamano <gitster@pobox.com>