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

#!/bin/sh

test_description='properly cull all ancestors'

. ./test-lib.sh

test_expect_success setup '

	touch file &&
	git add file &&

	test_commit one &&

	test_tick=$(($test_tick - 2400)) &&

	test_commit two &&
	test_commit three &&
	test_commit four &&

	git log --pretty=oneline --abbrev-commit
'

test_expect_success 'one is ancestor of others and should not be shown' '

	git rev-list one --not four >result &&
	>expect &&
	test_cmp expect result

'

test_done
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> 2008-02-02 23:47:22 -08:00			`#!/bin/sh`

			`test_description='properly cull all ancestors'`

			`. ./test-lib.sh`

			`test_expect_success setup '`

			`touch file &&`
			`git add file &&`

t6009: use test_commit() from test-lib.sh Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2011-03-21 11:14:05 +01:00			`test_commit one &&`
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> 2008-02-02 23:47:22 -08:00
tests: add missing && Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2010-10-30 20:46:54 -05:00			`test_tick=$(($test_tick - 2400)) &&`
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> 2008-02-02 23:47:22 -08:00
t6009: use test_commit() from test-lib.sh Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2011-03-21 11:14:05 +01:00			`test_commit two &&`
			`test_commit three &&`
			`test_commit four &&`
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> 2008-02-02 23:47:22 -08:00
			`git log --pretty=oneline --abbrev-commit`
			`'`

Make revision limiting more robust against occasional bad commit dates 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-17 18:56:33 -07:00			`test_expect_success 'one is ancestor of others and should not be shown' '`
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> 2008-02-02 23:47:22 -08:00
			`git rev-list one --not four >result &&`
			`>expect &&`
add test_cmp function for test scripts 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-03-12 17:36:36 -04:00			`test_cmp expect result`
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> 2008-02-02 23:47:22 -08:00
			`'`

			`test_done`