Re: make test Unexpected passes
On Wed, Apr 27, 2016 at 3:05 PM, Junio C Hamano wrote: > Isn't what the test expects bogus in the first place? I'd suggest > removing the test as "pointless waste of resource". > > Comments? > > -- >8 -- Yes, toss it; I find your arguments below compelling. > Manual merge resolution by users fundamentally depends on being able > to tell what is the tracked contents and what is the separator lines > added by "git merge" to tell users which block of lines came from > where. You can deliberately craft a file with lines that resemble > conflict marker lines to make it impossible for the user (here, the > outer merge of merge-recursive also counts as a user of the internal > merge) to tell which part is which, and write a test to demonstrate > that with such a file that "git merge" fundamentally cannot work > with and has to fail on. It however is pointless and waste of time > and resource to run such a test that asserts the obvious. > > In real life, people who do need to track files with such lines that > have as their prefixes set the conflict-marker-size > attribute to make sure they will be able to tell between the tracked > lines that happen to begin with these (confusing) prefixes and the > marker lines that are added by "git merge". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test Unexpected passes
Elijah Newren writes: > Yeah, the t6036 testcase 'git detects conflict w/ > criss-cross+contrived resolution' could be made to pass by tweaking > the conflict markers. In fact, any tweak would make it appear to > pass, but the test could be updated to still fail by updating the > contrived resolution of a previous merge to use the newer conflict > marker style as well. Isn't what the test expects bogus in the first place? I'd suggest removing the test as "pointless waste of resource". Comments? -- >8 -- Subject: [PATCH] t6036: remove pointless test that expects failure One test in t6036 prepares a file whose contents contain these lines: <<< Temporary merge branch 1 C === B >>> Temporary merge branch 2 and uses recursive merge strategy to run criss-cross merge with it. Manual merge resolution by users fundamentally depends on being able to tell what is the tracked contents and what is the separator lines added by "git merge" to tell users which block of lines came from where. You can deliberately craft a file with lines that resemble conflict marker lines to make it impossible for the user (here, the outer merge of merge-recursive also counts as a user of the internal merge) to tell which part is which, and write a test to demonstrate that with such a file that "git merge" fundamentally cannot work with and has to fail on. It however is pointless and waste of time and resource to run such a test that asserts the obvious. In real life, people who do need to track files with such lines that have as their prefixes set the conflict-marker-size attribute to make sure they will be able to tell between the tracked lines that happen to begin with these (confusing) prefixes and the marker lines that are added by "git merge". Remove the test as pointless waste of resource. Signed-off-by: Junio C Hamano --- t/t6036-recursive-corner-cases.sh | 83 --- 1 file changed, 83 deletions(-) diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh index cc1ee6a..c7b0ae6 100755 --- a/t/t6036-recursive-corner-cases.sh +++ b/t/t6036-recursive-corner-cases.sh @@ -304,89 +304,6 @@ test_expect_success 'git detects conflict merging criss-cross+modify/delete, rev test $(git rev-parse :3:file) = $(git rev-parse B:file) ' -# -# criss-cross + modify/modify with very contrived file contents: -# -# B D -# o---o -# / \ / \ -# A o X ? F -# \ / \ / -# o---o -# C E -# -# Commit A: file with contents 'A\n' -# Commit B: file with contents 'B\n' -# Commit C: file with contents 'C\n' -# Commit D: file with contents 'D\n' -# Commit E: file with contents: -# <<< Temporary merge branch 1 -# C -# === -# B -# >>> Temporary merge branch 2 -# -# Now, when we merge commits D & E, does git detect the conflict? - -test_expect_success 'setup differently handled merges of content conflict' ' - git clean -fdqx && - rm -rf .git && - git init && - - echo A >file && - git add file && - test_tick && - git commit -m A && - - git branch B && - git checkout -b C && - echo C >file && - git add file && - test_tick && - git commit -m C && - - git checkout B && - echo B >file && - git add file && - test_tick && - git commit -m B && - - git checkout B^0 && - test_must_fail git merge C && - echo D >file && - git add file && - test_tick && - git commit -m D && - git tag D && - - git checkout C^0 && - test_must_fail git merge B && - cat>> Temporary merge branch 2 -EOF - git add file && - test_tick && - git commit -m E && - git tag E -' - -test_expect_failure 'git detects conflict w/ criss-cross+contrived resolution' ' - git checkout D^0 && - - test_must_fail git merge -s recursive E^0 && - - test 3 -eq $(git ls-files -s | wc -l) && - test 3 -eq $(git ls-files -u | wc -l) && - test 0 -eq $(git ls-files -o | wc -l) && - - test $(git rev-parse :2:file) = $(git rev-parse D:file) && - test $(git rev-parse :3:file) = $(git rev-parse E:file) -' - # # criss-cross + d/f conflict via add/add: # Commit A: Neither file 'a' nor directory 'a/' exists. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test Unexpected passes
Ben Woosley writes: > These know breakages: > > ok 50 - rebase -m --onto --root > ok 54 - rebase -m without --onto --root with disjoint history > > Have to do with rebasing a root/orphan branch with the -m flag, > which defaults to -- merge=recursive, which is the case the patch fixed. > > Here are the necessary changes: > ... Thanks, will squash them in and reword the log message accordingly. git-rebase--merge: don't include absent parent as a base Absent this fix, attempts to rebase an orphan branch using "rebase -m" fails with: $ git rebase -m ORPHAN_TARGET_BASE First, rewinding head to replay your work on top of it... ... Note the default rebase behavior does not fail: $ git rebase ORPHAN_TARGET_BASE First, rewinding head to replay your work on top of it... Applying: ORPHAN_ROOT_COMMIT_MSG Using index info to reconstruct a base tree... A few tests were expecting the old behaviour to forbid rebasing such a history with "rebase -m", which now need to expect them to succeed. Signed-off-by: Ben Woosley Signed-off-by: Junio C Hamano -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test Unexpected passes
Ramsay Jones ramsayjones.plus.com> writes:
>
> Hi Ben, Junio,
>
> Tonight, the testsuite passed with a couple of 'unexpected passes', viz:
>
> In the first case, t3421-*.sh, git bisect fingered commit f32ec670
> ("git-rebase--merge: don't include absent parent as a base", 20-04-2016).
>
> ATB,
> Ramsay Jones
>
Yep,
These know breakages:
ok 50 - rebase -m --onto --root
ok 54 - rebase -m without --onto --root with disjoint history
Have to do with rebasing a root/orphan branch with the -m flag,
which defaults to -- merge=recursive, which is the case the patch fixed.
Here are the necessary changes:
--- a/t/t3421-rebase-topology-linear.sh
+++ b/t/t3421-rebase-topology-linear.sh
@@ -253,7 +253,7 @@ test_run_rebase () {
"
}
test_run_rebase success ''
-test_run_rebase failure -m
+test_run_rebase success -m
test_run_rebase success -i
test_run_rebase success -p
@@ -268,7 +268,7 @@ test_run_rebase () {
"
}
test_run_rebase success ''
-test_run_rebase failure -m
+test_run_rebase success -m
test_run_rebase success -i
test_run_rebase failure -p
--
2.8.1.211.g8e54d77
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test Unexpected passes
On Fri, Apr 22, 2016 at 1:05 PM, Ramsay Jones
wrote:
> Hi Ben, Junio,
>
> In the second case, t6036-*.sh, git bisect fingered commit b61f9d6e
> ("ll-merge: use a longer conflict marker for internal merge", 14-04-2016).
Yeah, the t6036 testcase 'git detects conflict w/
criss-cross+contrived resolution' could be made to pass by tweaking
the conflict markers. In fact, any tweak would make it appear to
pass, but the test could be updated to still fail by updating the
contrived resolution of a previous merge to use the newer conflict
marker style as well.
The test is kind of fragile in this way, and is really there just to
document this slightly weird and never seen in practice corner case.
I don't think we'll ever fix the underlying "problem"; not even sure
if it's possible without fundamentally re-thinking our merge strategy
altogether. I just thought that when I was writing all those tests
that documenting this particular behavior as a testcase had some
value, but if the conflict markers are going to be updated
periodically, then the cost of the test may outweigh its value and we
should just toss this one test from that file.
Elijah
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'make test' fails in pu
Jeff King writes: > Sometimes a breakage in pu is surprising (e.g., it breaks only on a > platform that the maintainer does not run "make test" on) and we would > want to know about it. But sometimes it is merely that there is a > work-in-progress. And it probably requires a human to tell the > difference. > > So no, I do not think automatically mailing on test failures in pu is a > good idea. Manually peeking at them and sending fixes before the series > is merged to next _is_ very much encouraged, though. :) Thanks, that is exactly what people saw. From time to time, I queue a topic that does not pass the tests on 'pu', hoping that somebody sufficiently interested would step in to collaborate with the author of the topic to move things forward when the breakage looks simple enough, and sometimes that original author happens to be me. This case, it turns out that the breakage is not so simple, though. Inside the rename detection logic, I want to peek the rename source array to decide which deletion filepair to keep, but rename source array itself has pointers to the original filepairs the loop wants to free, so the WIP code was peeking into a freed piece memory X-<. > Unlike "pu", "next" and "master" should never fail tests (I think that > Junio will not push them out if the tests have failed on his system). So > failures there are much more likely to be interesting platform bugs (but > of course, testing "pu" is still encouraged, as we may catch problems). True. I do not mind automated tests on 'next', and testing 'pu' and helping the topic to move forward is very much encouraged, but sending test results on 'pu' blindly is often more noise than it is worth. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'make test' fails in pu
For the record, that commit also sporadically breaks test 3910 on my system (mentioning since it's not on the list) On Tue, Feb 17, 2015 at 12:55 AM, Jeff King wrote: > On Tue, Feb 17, 2015 at 09:39:17AM +0100, Dennis Kaarsemaker wrote: > >> Make test has been failing for 'pu' yesterday for and today at >> t4016-diff-quote.sh. Full log: >> http://ci.kaarsemaker.net/git/refs/heads/pu/1df29c71a731c679de9055ae5e407f3a4e18740a/artefact/test/log >> >> I noticed this a few times before and it tends to get fixed again >> relatively quickly. So I'm wondering: >> >> - Should I even mention that it's failing, or is that just useless >> noise? >> - If I should report this, I could also make my testing thing send >> mails. Would that be useful? > > If you bisect this, it turns up commit 30cd8f94f, which says: > > WIP: diff-b-m > > [...] > > This update is still broken and breaks a handful of tests: > > 4016 4023 4047 4130 6022 6031 6032 9300 9200 9300 9350 > > Sometimes a breakage in pu is surprising (e.g., it breaks only on a > platform that the maintainer does not run "make test" on) and we would > want to know about it. But sometimes it is merely that there is a > work-in-progress. And it probably requires a human to tell the > difference. > > So no, I do not think automatically mailing on test failures in pu is a > good idea. Manually peeking at them and sending fixes before the series > is merged to next _is_ very much encouraged, though. :) > > Unlike "pu", "next" and "master" should never fail tests (I think that > Junio will not push them out if the tests have failed on his system). So > failures there are much more likely to be interesting platform bugs (but > of course, testing "pu" is still encouraged, as we may catch problems). > > But even for "next", I would say blind automated emails are not nearly > as useful as a human who has looked at the problem (and especially > bisected). > > -Peff > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'make test' fails in pu
On Tue, Feb 17, 2015 at 09:39:17AM +0100, Dennis Kaarsemaker wrote: > Make test has been failing for 'pu' yesterday for and today at > t4016-diff-quote.sh. Full log: > http://ci.kaarsemaker.net/git/refs/heads/pu/1df29c71a731c679de9055ae5e407f3a4e18740a/artefact/test/log > > I noticed this a few times before and it tends to get fixed again > relatively quickly. So I'm wondering: > > - Should I even mention that it's failing, or is that just useless > noise? > - If I should report this, I could also make my testing thing send > mails. Would that be useful? If you bisect this, it turns up commit 30cd8f94f, which says: WIP: diff-b-m [...] This update is still broken and breaks a handful of tests: 4016 4023 4047 4130 6022 6031 6032 9300 9200 9300 9350 Sometimes a breakage in pu is surprising (e.g., it breaks only on a platform that the maintainer does not run "make test" on) and we would want to know about it. But sometimes it is merely that there is a work-in-progress. And it probably requires a human to tell the difference. So no, I do not think automatically mailing on test failures in pu is a good idea. Manually peeking at them and sending fixes before the series is merged to next _is_ very much encouraged, though. :) Unlike "pu", "next" and "master" should never fail tests (I think that Junio will not push them out if the tests have failed on his system). So failures there are much more likely to be interesting platform bugs (but of course, testing "pu" is still encouraged, as we may catch problems). But even for "next", I would say blind automated emails are not nearly as useful as a human who has looked at the problem (and especially bisected). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test
"Joachim Schmitz" schrieb im Newsbeitrag
news:...
> Hi folks
>
> I'm trying to understand why certain tests in 'make test' fail. Here's the
> first one
>
> $ ../git --version
> git version 1.8.0.rc2.5.g6b89306
> $ GIT_TEST_CMP_USE_COPIED_CONTEXT=true ./t-basic.sh # our diff doesn't
> understand -u
> ok 1 - .git/objects should be empty after git init in an empty repo
> ...
> ok 3 - success is reported like this
> not ok 4 - pretend we have a known breakage # TODO known breakage
>
> This is expected, right?
>
> ok 5 - pretend we have fixed a known breakage (run in sub test-lib)
> ...
> ok 11 - tests clean up after themselves
>
> the next is not though? Why might it be failing, where to check?
>
> not ok - 12 tests clean up even on failures
> #
> # mkdir failing-cleanup &&
> # (
> # cd failing-cleanup &&
> #
> # cat >failing-cleanup.sh <<-EOF &&
> # #!/bin/sh
> #
> # test_description='Failing tests with cleanup commands'
> #
> # # Point to the t/test-lib.sh, which isn't in ../ as usual
> # TEST_DIRECTORY="/home/jojo/git/git/t"
> # . "$TEST_DIRECTORY"/test-lib.sh
> #
> # test_expect_success 'tests clean up even after a failure' '
> # touch clean-after-failure &&
> # test_when_finished rm clean-after-failure &&
> # (exit 1)
> # '
> # test_expect_success 'failure to clean up causes the test to
> fail' '
> # test_when_finished "(exit 2)"
> # '
> # test_done
> #
> # EOF
> #
> # chmod +x failing-cleanup.sh &&
> # test_must_fail ./failing-cleanup.sh >out 2>err &&
> # ! test -s err &&
> # ! test -f "trash
> directory.failing-cleanup/clean-after-failure" &&
> # sed -e 's/Z$//' -e 's/^> //' >expect <<-\EOF &&
> # > not ok - 1 tests clean up even after a failure
> # > # Z
> # > # touch clean-after-failure &&
> # > # test_when_finished rm clean-after-failure &&
> # > # (exit 1)
> # > # Z
> # > not ok - 2 failure to clean up causes the test to fail
> # > # Z
> # > # test_when_finished "(exit 2)"
> # > # Z
> # > # failed 2 among 2 test(s)
> # > 1..2
> # EOF
> # test_cmp expect out
> # )
> #
> ok 13 - git update-index without --add should fail adding
> ...
> ok 47 - very long name in the index handled sanely
> # still have 1 known breakage(s)
> # failed 1 among remaining 46 test(s)
> 1..47
As mentioned elsethread this works if using bash rather than the system's sh
(which is a ksh)
But there are several other failures. After some investigations and experiments
I found the following tests to fail with the system
provided grep (for which I had to set GIT_TEST_CMP_USE_COPIED_CONTEXT), but
succeed with GNU grep:
t3308 #14, #15, #17and #19
t3310 #10, #12, #14 and #18
t4047 #38 and #39
t4050 #2 and #3
t4116 #3, #4 and #5
t5509 #2
t7401 #18
The following fail with the system provided tar, but succeed with GNU tar:
t0024 #2
t4116 #4,
t5000 #14, #16, #20, #24, #26 and #51
t5001 #2, #6, #10 and #15
The following tests fail with the system provided sh (which is a ksh really),
but succeed with bash:
t #12
t0001 #20
t1450 #17 and #18
(t0204 #3 and #8 succeed in sh but fail in bash. They succeed in bash too when
/usr/local/bin is in PATH first though, which would
sort the diff and tar problem too, need to investigate why)
t3006 #2 and #3
t3403 #4, #5, #8 and #9
t3404 #2 - #13, #14 - #18, #20 - #41, #44, #46 - #70
t3409 #2 - #5
t3410 #2 and #3
t3411 #2 and #3
t3412 #8, #10 - #12, #15, #17, #23, #25, -26, #28, #29, #31
t3413 #3, #5 - #10, #14, #15
and many more...
The following needs bash and /usr/local/bin first in PATH
("PATH=/usr/local/bin:$PATH make test")
t0204 #3 and #8 (or just sh, see above)
t3032 #11
t3900 #24, #25
t4201 #8
t5000 #14
t5150 #6
I though "SANE_TOOL_PATH=/usr/local/bin" plus "SHELL_PATH=/usr/local/bin/bash"
would to fix the all but it does not and instead
brings up some other failures too:
t5521 #2 and #5
t5526 #2, #5, #8, #10, #12, #13, #16 - #19, #21 - #25
t5702 #3
t5800 #2, #3, #5 - #14
t9001 #66
With additionally having "PATH=/usr/local/bin:$PATH" all but one work, so there
must be something wrong with SANE_TOOL_PATH?.
The single failure remaining is
t0301 #12 "helper (cache --timeout=1) times out"
I don't understand this at all, neither the -v options nor running it with bash
-x helps me in understanding what the issue is.
Bye, Jojo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
RE: make test
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de] > Sent: Monday, October 15, 2012 3:18 PM > To: 'Andreas Schwab'; 'Johannes Sixt' > Cc: 'git@vger.kernel.org' > Subject: RE: make test > > > From: Andreas Schwab [mailto:sch...@linux-m68k.org] > > Sent: Monday, October 15, 2012 2:35 PM > > To: Johannes Sixt > > Cc: Joachim Schmitz; git@vger.kernel.org > > Subject: Re: make test > > > > Johannes Sixt writes: > > > > > Am 10/15/2012 13:58, schrieb Joachim Schmitz: > > >> ++ mkdir failing-cleanup > > >> ++ cd failing-cleanup > > >> ++ cat > > >> ++ chmod +x failing-cleanup.sh > > >> ++ test_must_fail ./failing-cleanup.sh > > >> + eval_ret=1 > > > > > > I wonder why the log does not show the commands of function > > > test_must_fail. > > > > That's because stderr is redirected. > > > > cat err > ++ ./failing-cleanup.sh > ++ exit_code=0 > ++ test 0 = 0 > ++ echo 'test_must_fail: command succeeded: ./failing-cleanup.sh' > test_must_fail: command succeeded: ./failing-cleanup.sh > ++ return 1 That test (as well as quite a few more) do pass when using bash rather than our sh (which really is a ksh) Bye, Jojo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: make test
> From: Andreas Schwab [mailto:sch...@linux-m68k.org] > Sent: Monday, October 15, 2012 2:35 PM > To: Johannes Sixt > Cc: Joachim Schmitz; git@vger.kernel.org > Subject: Re: make test > > Johannes Sixt writes: > > > Am 10/15/2012 13:58, schrieb Joachim Schmitz: > >> ++ mkdir failing-cleanup > >> ++ cd failing-cleanup > >> ++ cat > >> ++ chmod +x failing-cleanup.sh > >> ++ test_must_fail ./failing-cleanup.sh > >> + eval_ret=1 > > > > I wonder why the log does not show the commands of function > > test_must_fail. > > That's because stderr is redirected. > cat err ++ ./failing-cleanup.sh ++ exit_code=0 ++ test 0 = 0 ++ echo 'test_must_fail: command succeeded: ./failing-cleanup.sh' test_must_fail: command succeeded: ./failing-cleanup.sh ++ return 1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: make test
> From: Johannes Sixt [mailto:j.s...@viscovery.net] > Sent: Monday, October 15, 2012 2:10 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: make test > > Am 10/15/2012 13:58, schrieb Joachim Schmitz: > > ++ mkdir failing-cleanup > > ++ cd failing-cleanup > > ++ cat > > ++ chmod +x failing-cleanup.sh > > ++ test_must_fail ./failing-cleanup.sh > > + eval_ret=1 > > I wonder why the log does not show the commands of function > test_must_fail. Is there a 'set +x' hidden somewhere? Run > ./failing-cleanup.sh manually. Check its exit code (it should be non-zero, > but not something strange like 127 and above; see test_must_fail()) and > dig further from there. I'll stop here. It returns 0. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test
Johannes Sixt writes: > Am 10/15/2012 13:58, schrieb Joachim Schmitz: >> ++ mkdir failing-cleanup >> ++ cd failing-cleanup >> ++ cat >> ++ chmod +x failing-cleanup.sh >> ++ test_must_fail ./failing-cleanup.sh >> + eval_ret=1 > > I wonder why the log does not show the commands of function > test_must_fail. That's because stderr is redirected. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test
Am 10/15/2012 13:58, schrieb Joachim Schmitz: > ++ mkdir failing-cleanup > ++ cd failing-cleanup > ++ cat > ++ chmod +x failing-cleanup.sh > ++ test_must_fail ./failing-cleanup.sh > + eval_ret=1 I wonder why the log does not show the commands of function test_must_fail. Is there a 'set +x' hidden somewhere? Run ./failing-cleanup.sh manually. Check its exit code (it should be non-zero, but not something strange like 127 and above; see test_must_fail()) and dig further from there. I'll stop here. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: make test
> -Original Message- > From: Johannes Sixt [mailto:j.s...@viscovery.net] > Sent: Monday, October 15, 2012 1:53 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: make test > > Am 10/15/2012 13:37, schrieb Joachim Schmitz: > > ... > > + eval ' > > find .git/objects -type f -print >should-be-empty && > > test_line_count = 0 should-be-empty > > ' > > ++ find .git/objects -type f -print > > ++ test_line_count = 0 should-be-empty > > ++ test 3 '!=' 3 > > +++ wc -l > > ++ test 0 = 0 > > + eval_ret=0 > > This is the key line. If it is 'eval_ret=1' (or other non-zero value), > then the test failed, and the lines above it usually indicate where in the > test snippet the failure occurred. ... ++ mkdir failing-cleanup ++ cd failing-cleanup ++ cat ++ chmod +x failing-cleanup.sh ++ test_must_fail ./failing-cleanup.sh + eval_ret=1 + test -z t + test 1 = 0 + test -n '' + test t = t + test -n '' + return 1 + test_failure_ 'tests clean up even on failures' ' ... This part? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: make test
Am 10/15/2012 13:37, schrieb Joachim Schmitz: > ... > + eval ' > find .git/objects -type f -print >should-be-empty && > test_line_count = 0 should-be-empty > ' > ++ find .git/objects -type f -print > ++ test_line_count = 0 should-be-empty > ++ test 3 '!=' 3 > +++ wc -l > ++ test 0 = 0 > + eval_ret=0 This is the key line. If it is 'eval_ret=1' (or other non-zero value), then the test failed, and the lines above it usually indicate where in the test snippet the failure occurred. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: make test
> From: Johannes Sixt [mailto:j.s...@viscovery.net]
> Sent: Monday, October 15, 2012 1:18 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: make test
>
> Am 10/15/2012 13:00, schrieb Joachim Schmitz:
> >> From: Johannes Sixt [mailto:j.s...@viscovery.net]
> >> and if that does not give sufficient clues,
> >>
> >> $SHELL_PATH -x ./t-basic.sh -v -i
> >
> > not ok - 12 tests clean up even on failures
> > #...
> > + die
> >
> > Looks identical, except for the "die" at the end. And still leaves me
> > without a clue...
>
> When I do that it begins like this (I'm on Windows):
>
> D:\Src\mingw-git\t>bash -x t-basic.sh -v -i
> + test_description='Test the very basics part #1.
> ...
> '
> + . ./test-lib.sh
> ++ ORIGINAL_TERM=cygwin
> ++ test -z ''
> +++ pwd
> ++ TEST_DIRECTORY=/d/Src/mingw-git/t
> ++ test -z ''
> ++ TEST_OUTPUT_DIRECTORY=/d/Src/mingw-git/t
> ++ GIT_BUILD_DIR=/d/Src/mingw-git/t/..
> ++ /d/Src/mingw-git/t/../git
> ++ test 1 '!=' 1
> ++ . /d/Src/mingw-git/t/../GIT-BUILD-OPTIONS
> +++ SHELL_PATH=/bin/sh
> +++ PERL_PATH=/usr/bin/perl
> +++ DIFF=diff
> +++ PYTHON_PATH=/usr/bin/python
> +++ TAR=tar
> ...
>
> It seems you need a shell that is verbose under -x.
Erm, no, I left that part out...
+ . ./test-lib.sh
++ ORIGINAL_TERM=dumb
++ test -z ''
+++ pwd
++ TEST_DIRECTORY=/home/jojo/git/git/t
++ test -z ''
++ TEST_OUTPUT_DIRECTORY=/home/jojo/git/git/t
++ GIT_BUILD_DIR=/home/jojo/git/git/t/..
++ /home/jojo/git/git/t/../git
++ test 1 '!=' 1
++ . /home/jojo/git/git/t/../GIT-BUILD-OPTIONS
+++ SHELL_PATH=/bin/sh
+++ PERL_PATH=/usr/local/bin/perl
+++ DIFF=diff
+++ PYTHON_PATH=/usr/local/bin/python
+++ TAR=tar
+++ NO_CURL=
+++ USE_LIBPCRE=
+++ NO_PERL=
+++ NO_PYTHON=
+++ NO_UNIX_SOCKETS=
+++ GIT_TEST_CMP_USE_COPIED_CONTEXT=YesPlease
+++ NO_GETTEXT=
+++ GETTEXT_POISON=
++ export PERL_PATH SHELL_PATH
++ case "$GIT_TEST_TEE_STARTED, $* " in
++ LANG=C
++ LC_ALL=C
++ PAGER=cat
++ TZ=UTC
++ TERM=dumb
++ export LANG LC_ALL PAGER TERM TZ
++ EDITOR=:
+++ /usr/local/bin/perl -e '
my @env = keys %ENV;
my $ok = join("|", qw(
TRACE
DEBUG
USE_LOOKUP
TEST
.*_TEST
PROVE
VALGRIND
PERF_AGGREGATING_LATER
));
my @vars = grep(/^GIT_/ && !/^GIT_($ok)/o, @env);
print join("\n", @vars);
'
++ unset VISUAL EMAIL LANGUAGE COLUMNS GIT_AUTHOR_NAME GIT_MERGE_AUTOEDIT
GIT_EXEC_PATH GIT_ATTR_NOSYSTEM GIT_MERGE_VERBOSITY
GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
++ unset XDG_CONFIG_HOME
++ GIT_AUTHOR_EMAIL=aut...@example.com
++ GIT_AUTHOR_NAME='A U Thor'
++ GIT_COMMITTER_EMAIL=commit...@example.com
++ GIT_COMMITTER_NAME='C O Mitter'
++ GIT_MERGE_VERBOSITY=5
++ GIT_MERGE_AUTOEDIT=no
++ export GIT_MERGE_VERBOSITY GIT_MERGE_AUTOEDIT
++ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
++ export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
++ export EDITOR
++ expr ' ' : '.* --valgrind '
++ test -n ''
++ unset CDPATH
++ unset GREP_OPTIONS
++ case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
+++ echo
+++ tr '[A-Z]' '[a-z]'
++ _x05='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
++
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-
f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0
-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
++ _z40=
++ LF='
'
++ export _x05 _x40 _z40 LF
++ '[' xdumb '!=' xdumb ']'
++ test 2 -ne 0
++ case "$1" in
++ verbose=t
++ shift
++ test 1 -ne 0
++ case "$1" in
++ immediate=t
++ shift
++ test 0 -ne 0
++ test -n ''
++ test 'Test the very basics part #1.
The rest of the test suite does not check the basic operation of git
plumbing commands to work very carefully. Their job is to concentrate
on tricky features that caused bugs in the past to detect regression.
This test runs very basic features, like registering things in cache,
writing tree, etc.
Note that this test *deliberately* hard-codes many expected object
IDs. When object ID computation changes, like in the previous case of
swapping compression and hashing order, the person who is making the
modification *should* take notice and update the test vectors here.
' '!=' ''
++ test '' = t
++ exec
++ exec
+
Re: make test
Am 10/15/2012 13:00, schrieb Joachim Schmitz: >> From: Johannes Sixt [mailto:j.s...@viscovery.net] >> and if that does not give sufficient clues, >> >> $SHELL_PATH -x ./t-basic.sh -v -i > > not ok - 12 tests clean up even on failures > #... > + die > > Looks identical, except for the "die" at the end. And still leaves me without > a clue... When I do that it begins like this (I'm on Windows): D:\Src\mingw-git\t>bash -x t-basic.sh -v -i + test_description='Test the very basics part #1. ... ' + . ./test-lib.sh ++ ORIGINAL_TERM=cygwin ++ test -z '' +++ pwd ++ TEST_DIRECTORY=/d/Src/mingw-git/t ++ test -z '' ++ TEST_OUTPUT_DIRECTORY=/d/Src/mingw-git/t ++ GIT_BUILD_DIR=/d/Src/mingw-git/t/.. ++ /d/Src/mingw-git/t/../git ++ test 1 '!=' 1 ++ . /d/Src/mingw-git/t/../GIT-BUILD-OPTIONS +++ SHELL_PATH=/bin/sh +++ PERL_PATH=/usr/bin/perl +++ DIFF=diff +++ PYTHON_PATH=/usr/bin/python +++ TAR=tar ... It seems you need a shell that is verbose under -x. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: make test
> From: Johannes Sixt [mailto:j.s...@viscovery.net] > Sent: Monday, October 15, 2012 12:53 PM > To: Joachim Schmitz > Cc: git@vger.kernel.org > Subject: Re: make test > > Am 10/15/2012 12:36, schrieb Joachim Schmitz: > > not ok 4 - pretend we have a known breakage # TODO known breakage > > > >This is expected, right? > > Right. > > >the next is not though? Why might it be failing, where to check? > > > > not ok - 12 tests clean up even on failures > > # > > # mkdir failing-cleanup && > > #... > > # test_cmp expect out > > # ) > > # > > First thing: > > ./t-basic.sh -v -i OK, I should have mentioned that I did look with -v : not ok - 12 tests clean up even on failures # # mkdir failing-cleanup && # ( # cd failing-cleanup && # # cat >failing-cleanup.sh <<-EOF && # #!/bin/sh # # test_description='Failing tests with cleanup commands' # # # Point to the t/test-lib.sh, which isn't in ../ as usual # TEST_DIRECTORY="/home/jojo/git/git/t" # . "$TEST_DIRECTORY"/test-lib.sh # # test_expect_success 'tests clean up even after a failure' ' # touch clean-after-failure && # test_when_finished rm clean-after-failure && # (exit 1) # ' # test_expect_success 'failure to clean up causes the test to fail' ' # test_when_finished "(exit 2)" # ' # test_done # # EOF # # chmod +x failing-cleanup.sh && # test_must_fail ./failing-cleanup.sh >out 2>err && # ! test -s err && # ! test -f "trash directory.failing-cleanup/clean-after-failure" && # sed -e 's/Z$//' -e 's/^> //' >expect <<-\EOF && # > not ok - 1 tests clean up even after a failure # > # Z # > # touch clean-after-failure && # > # test_when_finished rm clean-after-failure && # > # (exit 1) # > # Z # > not ok - 2 failure to clean up causes the test to fail # > # Z # > # test_when_finished "(exit 2)" # > # Z # > # failed 2 among 2 test(s) # > 1..2 # EOF # test_cmp expect out # ) # > and if that does not give sufficient clues, > > $SHELL_PATH -x ./t-basic.sh -v -i not ok - 12 tests clean up even on failures # # mkdir failing-cleanup && # ( # cd failing-cleanup && # # cat >failing-cleanup.sh <<-EOF && # #!/bin/sh # # test_description='Failing tests with cleanup commands' # # # Point to the t/test-lib.sh, which isn't in ../ as usual # TEST_DIRECTORY="/home/jojo/git/git/t" # . "$TEST_DIRECTORY"/test-lib.sh # # test_expect_success 'tests clean up even after a failure' ' # touch clean-after-failure && # test_when_finished rm clean-after-failure && # (exit 1) # ' # test_expect_success 'failure to clean up causes the test to fail' ' # test_when_finished "(exit 2)" # ' # test_done # # EOF # # chmod +x failing-cleanup.sh && # test_must_fail ./failing-cleanup.sh >out 2>err && # ! test -s err && # ! test -f "trash directory.failing-cleanup/clean-after-failure" && # sed -e 's/Z$//' -e 's/^> //' >expect <<-\EOF && # > not ok - 1 tests clean up even after a failure # > # Z # > # touch clean-after-failure && # > # test_when_finished rm clean-after-failure && # > # (exit 1) # > # Z # > not ok - 2 failure to clean up causes the test to fail # > # Z # > # test_when_finished "(exit 2)" # > # Z # > #
Re: make test
Am 10/15/2012 12:36, schrieb Joachim Schmitz: > not ok 4 - pretend we have a known breakage # TODO known breakage > >This is expected, right? Right. >the next is not though? Why might it be failing, where to check? > > not ok - 12 tests clean up even on failures > # > # mkdir failing-cleanup && > #... > # test_cmp expect out > # ) > # First thing: ./t-basic.sh -v -i and if that does not give sufficient clues, $SHELL_PATH -x ./t-basic.sh -v -i (Beware, though: in some cases, the latter gives additional failures, in particular, when the stderr of a command is checked for with test_cmp instead of grep because the 'actual' results contain the shell command logs, which are not in the 'expected' results.) -- Hannes, -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
