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>
Junio C Hamano committed
Feb 2, 2008 at 23:47 UTC
991c3dc79f21a52209f9f41a52909cbb9462de1a
1 file changed
+38
t/t6009-rev-list-parent.sh
new
+38
@@ -0,0 +1,38 @@
1
+#!/bin/sh
2
+
3
+test_description='properly cull all ancestors'
4
+
5
+. ./test-lib.sh
6
+
7
+commit () {
8
+ test_tick &&
9
+ echo $1 >file &&
10
+ git commit -a -m $1 &&
11
+ git tag $1
12
+}
13
+
14
+test_expect_success setup '
15
+
16
+ touch file &&
17
+ git add file &&
18
+
19
+ commit one &&
20
+
21
+ test_tick=$(($test_tick - 2400))
22
+
23
+ commit two &&
24
+ commit three &&
25
+ commit four &&
26
+
27
+ git log --pretty=oneline --abbrev-commit
28
+'
29
+
30
+test_expect_failure 'one is ancestor of others and should not be shown' '
31
+
32
+ git rev-list one --not four >result &&
33
+ >expect &&
34
+ diff -u expect result
35
+
36
+'
37
+
38
+test_done