Browse Source

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>
maint
Junio C Hamano 17 years ago
parent
commit
991c3dc79f
  1. 38
      t/t6009-rev-list-parent.sh

38
t/t6009-rev-list-parent.sh

@ -0,0 +1,38 @@ @@ -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
Loading…
Cancel
Save