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>

1 files changed, 38 insertions, 0 deletions

diff --git a/t/t6009-rev-list-parent.sh b/t/t6009-rev-list-parent.sh
new file mode 100755
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