known breakage: revision range computation with clock skew

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>

diff --git a/t/t6009-rev-list-parent.sh b/t/t6009-rev-list-parent.sh
new file mode 100755 (executable)
index 0000000..be3d238
--- /dev/null
+++ b/t/t6009-rev-list-parent.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+test_description='properly cull all ancestors'
+
+. ./test-lib.sh
+
+commit () {
+       test_tick &&
+       echo $1 >file &&
+       git commit -a -m $1 &&
+       git tag $1
+}
+
+test_expect_success setup '
+
+       touch file &&
+       git add file &&
+
+       commit one &&
+
+       test_tick=$(($test_tick - 2400))
+
+       commit two &&
+       commit three &&
+       commit four &&
+
+       git log --pretty=oneline --abbrev-commit
+'
+
+test_expect_failure 'one is ancestor of others and should not be shown' '
+
+       git rev-list one --not four >result &&
+       >expect &&
+       diff -u expect result
+
+'
+
+test_done