Re: avoid "Set preference list" during make test?

On Tue, Aug 28, 2018 at 11:53:55PM +, Tacitus Aedifex wrote: > While running `make test` on the git source tree I keep getting asked: > > Set preference list to: >Cipher: ... >Digest: ... >etc... > > Is there any way to turn that prompt off so th

avoid "Set preference list" during make test?

While running `make test` on the git source tree I keep getting asked: Set preference list to: Cipher: ... Digest: ... etc... Is there any way to turn that prompt off so that `make test` completes without any keyboard input? //tæ

Re: [PATCH 0/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

Junio C Hamano wrote: > Todd Zullinger writes: >> I wanted to check if this minor patch series had slipped >> under your radar. > > Totally. Queued. > > As they come with Ack by the area maintainer, I'll fast-track them > down to 'master' (other topics typically cook at least

Re: [PATCH 0/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

Todd Zullinger writes: > I wanted to check if this minor patch series had slipped > under your radar. Totally. Queued. As they come with Ack by the area maintainer, I'll fast-track them down to 'master' (other topics typically cook at least for a week in 'next'). Thanks for

[PATCH 0/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

Hi Junio, I wanted to check if this minor patch series had slipped under your radar. If it's waiting patiently in your queue for other topics to advance, that's fine, of course. :) Finished patches: <20171201155653.29553-1-...@pobox.com> and <20171201155653.29553-2-...@pobox.com>. Thanks, --

Re: [PATCH v2 2/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

Todd Zullinger wrote: > Reviewed-by: Jonathan Nieder > Signed-off-by: Todd Zullinger > --- > t/lib-git-svn.sh | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) This and the previous one are indeed still Reviewed-by: Jonathan Nieder

[PATCH v2 2/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

Setting SVNSERVE_PORT enables several tests which require a local svnserve daemon to be run (in t9113 & t9126). The tests share setup of the local svnserve via `start_svnserve()`. The function uses svnserve's `--listen-once` option, which causes svnserve to accept one connection on the port,

Re: [PATCH 2/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

Jonathan Nieder wrote: Yep, with this description it is Reviewed-by: Jonathan Nieder Thanks for putting up with my nits. :) Thank you for taking the time and looking at the details. :) I'll send a v2 with the changes in the morning, in case there are any other comments

Re: [PATCH 2/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

ERVE to any value other than 'false' or 'auto' to enable these tests. Much better, thank you. How about this for the full commit message: t/lib-git-svn.sh: improve svnserve tests with parallel make test Setting SVNSERVE_PORT enables several tests which require a local svnserve da

Re: [PATCH 0/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

testing locally with parallel make test. The official fedora builds don't run in parallel (yet), as even before I ran into this issue, builds on the fedora builders randomly failed too often. I'm hoping to eventually enable parallel tests by default though, since it's so much faster

Re: [PATCH 0/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

Hi Eric, Eric Wong wrote: I'm fine with this for now. Since svnserve (and git-daemon) both support inetd behavior, I think we can eventually have a test helper which binds random ports and pretends to be an inetd, letting the test run without any special setup. It would let multiple test

Re: [PATCH 0/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

y with parallel make test. The > official fedora builds don't run in parallel (yet), as even before I ran > into this issue, builds on the fedora builders randomly failed too > often. I'm hoping to eventually enable parallel tests by default > though, since it's so much faster

Re: [PATCH 2/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

Hi, Todd Zullinger wrote: > Previously, setting SVNSERVE_PORT enabled several tests which require a > local svnserve daemon to be run (in t9113 & t9126). The tests share the > setup of the local svnserve via `start_svnserve()`. The function uses > the svnserve option `--listen-once` which

[PATCH 2/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

Previously, setting SVNSERVE_PORT enabled several tests which require a local svnserve daemon to be run (in t9113 & t9126). The tests share the setup of the local svnserve via `start_svnserve()`. The function uses the svnserve option `--listen-once` which causes svnserve to accept one connection

[PATCH 0/2] t/lib-git-svn.sh: improve svnserve tests with parallel make test

These tests are not run by default nor are they enabled in travis-ci. I don't know how much testing they get in user or other packager builds. I've been slowly increasing the test suite usage in fedora builds. I ran into this while testing locally with parallel make test. The official fedora

Re: [PATCH] p3400: make test script executable

René Scharfe writes: > Signed-off-by: Rene Scharfe > --- > This script was added by v2.10.0-rc0~3^2. Thanks. Will merge to 'master'. > > t/perf/p3400-rebase.sh | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > mode change 100644 => 100755

[PATCH] p3400: make test script executable

Signed-off-by: Rene Scharfe --- This script was added by v2.10.0-rc0~3^2. t/perf/p3400-rebase.sh | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 t/perf/p3400-rebase.sh diff --git a/t/perf/p3400-rebase.sh b/t/perf/p3400-rebase.sh old mode 100644

Re: [PATCH v2 2/3] Make test t3700-add.sh more robust

Ingo Brückl <i...@wupperonline.de> writes: > Subject: Re: [PATCH v2 2/3] Make test t3700-add.sh more robust Please check output from "git shortlog --no-merges -100" to see how your titles play well with others. We typically prefix the title with a specific area, a co

[PATCH v2 2/3] Make test t3700-add.sh more robust

Don't rely on chmod to work on the underlying platform (although it wouldn't harm the result of the '--chmod=-x' test). Directly check the result of the --chmod option. Add a test_mode_in_index helper function in order to check for success. Signed-off-by: Ingo Brückl ---

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

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

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

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,

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

make test Unexpected passes

Hi Ben, Junio, Tonight, the testsuite passed with a couple of 'unexpected passes', viz: $ tail -17 ptest-out [13:24:29] All tests successful. Test Summary Report --- t3421-rebase-topology-linear.sh (Wstat: 0 Tests: 76 Failed: 0) TODO passed: 50, 54

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Fri, Mar 25, 2016 at 2:15 PM, Pranit Bauva wrote: > On Fri, Mar 25, 2016 at 10:34 PM, Eric Sunshine > wrote: >> That works too, simplifying the overall implementation, and >> eliminating the need for the introductory patch which moves >>

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Fri, Mar 25, 2016 at 10:34 PM, Eric Sunshine wrote: > That works too, simplifying the overall implementation, and > eliminating the need for the introductory patch which moves > 'test_set_editor' into each test. Wouldn't it be cleaner if the introductory patch

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Fri, Mar 25, 2016 at 10:46 AM, SZEDER Gábor wrote: > Quoting Eric Sunshine : >> On Thu, Mar 24, 2016 at 7:00 AM, SZEDER Gábor wrote: -cat >check-for-diff <>>> -#!$SHELL_PATH -exec grep '^diff --git' "\$1"

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Fri, Mar 25, 2016 at 8:16 PM, SZEDER Gábor wrote: > By redirecting grep's output to a file in the editor script, like this > patch wanted to, we can count the lines in the test script itself after > 'git commit' finished. This way we could use test_line_count, with > all

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

Quoting Eric Sunshine : On Thu, Mar 24, 2016 at 7:00 AM, SZEDER Gábor wrote: diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh index 2ddf28c..cf95efb 100755 --- a/t/t7507-commit-verbose.sh +++ b/t/t7507-commit-verbose.sh @@ -3,12

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Fri, Mar 25, 2016 at 11:54 AM, Eric Sunshine wrote: > On Fri, Mar 25, 2016 at 2:06 AM, Pranit Bauva wrote: >> On Fri, Mar 25, 2016 at 5:27 AM, Eric Sunshine >> wrote: >>> Agreed that this needs proper justification in

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Fri, Mar 25, 2016 at 2:06 AM, Pranit Bauva wrote: > On Fri, Mar 25, 2016 at 5:27 AM, Eric Sunshine > wrote: >> Agreed that this needs proper justification in the commit message. >> And, the justification is to make each test more

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

om "editors" > set by earlier tests[1][2]. This shou cadve mbe ave be ave be ave be ave be ave be ave be ave > Another issue is that the commit message is backward. The subject > ("t7507-commit-verbose: make test suite use write_script") tries to > sell

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

second fake "editor", and by making tests responsible for setting the editor they need, they don't have to worry about bad interactions from "editors" set by earlier tests[1][2]. Another issue is that the commit message is backward. The subject ("t7507-commit-verbose: make

[PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

> Also remove test_set_editor from global scope and use it in whichever > test it is required. Why? test_set_editor sets and exports shell variables. Since you don't invoke test_set_editor in a subshell, after the first invocation the editor will be part of the global scope anyway. Also

[PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

Also remove test_set_editor from global scope and use it in whichever test it is required. --- t/t7507-commit-verbose.sh | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh index 2ddf28c..cf95efb 100755 ---

Bug when doing make test using root user

]: *** [t0302-credential-store.sh] Error 1 make[2]: Leaving directory `/root/git-2.4.3/t' make[1]: *** [test] Error 2 make[1]: Leaving directory `/root/git-2.4.3/t' make: *** [test] Error 2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord

Re: Bug when doing make test using root user

On Fri, Jun 12, 2015 at 5:43 PM, Jean-Yves LENHOF jean-y...@lenhof.eu.org wrote: Hi, I tried to compile git 2.4.3 using root on a server. It failed on test 41 of t0302-credential-store.sh In fact even if we remove read access on a directory, root still can acces this directory. Using a not

[PATCH] t1700: make test pass with index-v4

The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when run with index v4. Fix it. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- t/t1700-split-index.sh | 15 --- 1 file changed, 12 insertions(+), 3

[PATCH v2] t1700: make test pass with index-v4

The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when the test suite is run with TEST_GIT_INDEX_VERSION=4. Fix it. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- An updated patch to mention when run with

Re: [PATCH] t1700: make test pass with index-v4

Thomas Gummerer t.gumme...@gmail.com writes: The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when run with index v4. Fix it. I am more interested to see how you managed to use index v4 in the tests be described next to

Re: [PATCH] t1700: make test pass with index-v4

On 03/20, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when run with index v4. Fix it. I am more interested to see how you managed to use index

Re: [PATCH] t1700: make test pass with index-v4

Thomas Gummerer t.gumme...@gmail.com writes: On 03/20, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when run with index v4. Fix it. I am more

Re: [PATCH v2] t1700: make test pass with index-v4

Thomas Gummerer t.gumme...@gmail.com writes: The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when the test suite is run with TEST_GIT_INDEX_VERSION=4. Fix it. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- An

Re: [PATCH v2] t1700: make test pass with index-v4

On 03/20, Junio C Hamano wrote: Thomas Gummerer t.gumme...@gmail.com writes: The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when the test suite is run with TEST_GIT_INDEX_VERSION=4. Fix it. Signed-off-by: Thomas

Re: 'make test' fails in pu

Jeff King p...@peff.net 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

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 p...@peff.net wrote: On Tue, Feb 17, 2015 at 09:39:17AM +0100, Dennis Kaarsemaker wrote: Make test has been failing for 'pu' yesterday

'make test' fails in pu

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

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

t3200-branch.sh number 102 fails when run under make test

Hello, I recently cloned the master branch of the git repo, and when I ran make test, it fails on test 102 of the t3200-branch.sh test cases. not ok 102 - tracking with unexpected .fetch refspec # # rm -rf a b c d # git init

Re: t3200-branch.sh number 102 fails when run under make test

On Wed, Jul 09, 2014 at 08:37:51PM +, Keller, Jacob E wrote: I recently cloned the master branch of the git repo, and when I ran make test, it fails on test 102 of the t3200-branch.sh test cases. Just a guess, but try reverting 745224e (refs.c: SSE2 optimizations

Re: t3200-branch.sh number 102 fails when run under make test

On Wed, 2014-07-09 at 13:37 -0700, Jacob E Keller wrote: Hello, I recently cloned the master branch of the git repo, and when I ran make test, it fails on test 102 of the t3200-branch.sh test cases. not ok 102 - tracking with unexpected .fetch refspec # # rm -rf a b c d

Re: t3200-branch.sh number 102 fails when run under make test

On Wed, 2014-07-09 at 16:54 -0400, Jeff King wrote: On Wed, Jul 09, 2014 at 08:37:51PM +, Keller, Jacob E wrote: I recently cloned the master branch of the git repo, and when I ran make test, it fails on test 102 of the t3200-branch.sh test cases. Just a guess, but try reverting

Re: [PATCH 1/3] Make test using invalid commit with -C more strict

Jonathan Nieder jrnie...@gmail.com writes: Kacper Kornet wrote: In the test 'using invalid commit with -C' git-commit would have failed even if the -C option had been given the correct commit, as there was nothing to commit. Good catch. [...] --- a/t/t7501-commit.sh +++

Re: [PATCH 1/3] Make test using invalid commit with -C more strict

Junio C Hamano wrote: Kacper Kornet wrote: In the test 'using invalid commit with -C' git-commit would have failed even if the -C option had been given the correct commit, as there was nothing to commit. [...] Also it would be much simpler to say git commit --allow-empty. Sounds good. ;-)

Re: [PATCH 1/3] Make test using invalid commit with -C more strict

Kacper Kornet wrote: In the test 'using invalid commit with -C' git-commit would have failed even if the -C option had been given the correct commit, as there was nothing to commit. Good catch. [...] --- a/t/t7501-commit.sh +++ b/t/t7501-commit.sh @@ -53,7 +53,10 @@ test_expect_success

[PATCH 1/3] Make test using invalid commit with -C more strict

In the test 'using invalid commit with -C' git-commit would have failed even if the -C option had been given the correct commit, as there was nothing to commit. Fix it by making sure there is always something to commit and git-commit fails because of the invalid commit provided to it.

[PATCH 1/3] Make test using invalid commit with -C more strict

In the test 'using invalid commit with -C' git-commit would have failed even if the -C option had been given the correct commit, as there was nothing to commit. Fix it by making sure there is always something to commit and git-commit fails because of the invalid commit provided to it.

Re: [PATCH v6 0/7] make test output coloring more intuitive

On Sun, Dec 16, 2012 at 07:01:56PM +, Adam Spiers wrote: On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote: Adam Spiers g...@adamspiers.org writes: This series of commits attempts to make test output coloring more intuitive,... Thanks; I understand

Re: [PATCH v6 0/7] make test output coloring more intuitive

On Thu, Dec 20, 2012 at 3:34 PM, Jeff King p...@peff.net wrote: On Sun, Dec 16, 2012 at 07:01:56PM +, Adam Spiers wrote: On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote: Adam Spiers g...@adamspiers.org writes: This series of commits attempts to make test output

Re: [PATCH v6 0/7] make test output coloring more intuitive

On Thu, Dec 20, 2012 at 03:44:53PM +, Adam Spiers wrote: diff --git a/t/test-lib.sh b/t/test-lib.sh index 256f1c6..31f59af 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -227,7 +227,7 @@ then pass) tput setaf 2;;# green

Re: [PATCH v6 0/7] make test output coloring more intuitive

On Thu, Dec 20, 2012 at 4:11 PM, Jeff King p...@peff.net wrote: On Thu, Dec 20, 2012 at 03:44:53PM +, Adam Spiers wrote: diff --git a/t/test-lib.sh b/t/test-lib.sh index 256f1c6..31f59af 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -227,7 +227,7 @@ then pass)

Re: [PATCH v6 0/7] make test output coloring more intuitive

Jeff King p...@peff.net writes: Good point, I forgot to check what it looked like with -v. Since this series is already on v6, is there a more lightweight way of addressing this tiny tweak than sending v7? It is ultimately up to Junio, but I suspect he would be OK if you just reposted

Re: [PATCH v6 0/7] make test output coloring more intuitive

On Thu, Dec 20, 2012 at 11:21:09AM -0800, Junio C Hamano wrote: The expected_failure cases painted in warn are all long-known failures; I do not think reminding about them in bold over and over will help encouraging the developers take a look at them. The skipped cases fall into two

Re: [PATCH v6 0/7] make test output coloring more intuitive

On Thu, Dec 20, 2012 at 7:21 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: Good point, I forgot to check what it looked like with -v. Since this series is already on v6, is there a more lightweight way of addressing this tiny tweak than sending v7? It is

[PATCH v6 0/7] make test output coloring more intuitive

This series of commits attempts to make test output coloring more intuitive, so that: - red is only used for things which have gone unexpectedly wrong: test failures, unexpected test passes, and failures with the framework, - yellow is only used for known breakages, - green

Re: [PATCH v6 0/7] make test output coloring more intuitive

Adam Spiers g...@adamspiers.org writes: This series of commits attempts to make test output coloring more intuitive,... Thanks; I understand that this is to replace the previous one b465316 (tests: paint unexpectedly fixed known breakages in bold red, 2012-09-19)---am I correct? - red

Re: [PATCH v6 0/7] make test output coloring more intuitive

On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote: Adam Spiers g...@adamspiers.org writes: This series of commits attempts to make test output coloring more intuitive,... Thanks; I understand that this is to replace the previous one b465316 (tests: paint unexpectedly

Re: [PATCH v6 0/7] make test output coloring more intuitive

Adam Spiers g...@adamspiers.org writes: On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote: Adam Spiers g...@adamspiers.org writes: This series of commits attempts to make test output coloring more intuitive,... Thanks; I understand that this is to replace the previous

RE: [PATCH v2] fix 'make test' for HP NonStop

From: Jeff King [mailto:p...@peff.net] Sent: Monday, October 29, 2012 8:07 AM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH v2] fix 'make test' for HP NonStop On Thu, Oct 25, 2012 at 12:57:10PM +0200, Joachim Schmitz wrote: diff --git a/Makefile b/Makefile index

Re: [PATCH v2] fix 'make test' for HP NonStop

On Tue, Oct 30, 2012 at 10:21:40AM +0100, Joachim Schmitz wrote: This fixes the vast majority of test failures on HP NonStop. Some test don't work with /bin/diff, some fail with /bin/tar, so let's put /usr/local/bin in PATH first. Some tests fail with /bin/sh (link to /bin/ksh) so use bash

Re: [PATCH] fix 'make test' for HP NonStop

On Mon, Oct 22, 2012 at 04:30:17PM +0200, Joachim Schmitz wrote: + # for 'make test' + # some test don't work with /bin/diff, some fail with /bin/tar + # some need bash, and some need ${prefix}/bin in PATH first + SHELL_PATH=${prefix}/bin/bash + SANE_TOOL_PATH=${prefix

RE: [PATCH] fix 'make test' for HP NonStop

From: Jeff King [mailto:p...@peff.net] Sent: Thursday, October 25, 2012 11:58 AM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH] fix 'make test' for HP NonStop On Mon, Oct 22, 2012 at 04:30:17PM +0200, Joachim Schmitz wrote: + # for 'make test' + # some test

Re: [PATCH] fix 'make test' for HP NonStop

On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote: + # for 'make test' + # some test don't work with /bin/diff, some fail with /bin/tar + # some need bash, and some need ${prefix}/bin in PATH first + SHELL_PATH=${prefix}/bin/bash + SANE_TOOL_PATH=${prefix}/bin

RE: [PATCH] fix 'make test' for HP NonStop

From: Jeff King [mailto:p...@peff.net] Sent: Thursday, October 25, 2012 12:49 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH] fix 'make test' for HP NonStop On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote: + # for 'make test

Re: [PATCH] fix 'make test' for HP NonStop

On Thu, Oct 25, 2012 at 12:51:59PM +0200, Joachim Schmitz wrote: But then I would think using /usr/local would be the sane thing to put there, if that is the closest to standard for your platform. OK, yes, hardcoding /usr/local seems OK too. Would I need to re-roll? Please do. -Peff --

RE: [PATCH v2] fix 'make test' for HP NonStop

--- a/Makefile +++ b/Makefile @@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL) MKDIR_WO_TRAILING_SLASH = YesPlease # RFE 10-120912-4693 submitted to HP NonStop development. NO_SETITIMER = UnfortunatelyYes + + # for 'make test' + # some test don't work with /bin

RE: [PATCH] fix 'make test' for HP NonStop

From: Jeff King [mailto:p...@peff.net] Sent: Thursday, October 25, 2012 12:53 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: [PATCH] fix 'make test' for HP NonStop On Thu, Oct 25, 2012 at 12:51:59PM +0200, Joachim Schmitz wrote: But then I would think using /usr/local

Re: make test

Joachim Schmitz j...@schmitz-digital.de schrieb im Newsbeitrag news:k5gov5$fe1$1...@ger.gmane.org... 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

[PATCH] fix 'make test' for HP NonStop

development. NO_SETITIMER = UnfortunatelyYes + + # for 'make test' + # some test don't work with /bin/diff, some fail with /bin/tar + # some need bash, and some need ${prefix}/bin in PATH first + SHELL_PATH=${prefix}/bin/bash + SANE_TOOL_PATH=${prefix}/bin

make test

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

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

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

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

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

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 +

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

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

Re: make test

Johannes Sixt j.s...@viscovery.net 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

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

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 j.s...@viscovery.net writes: Am 10/15/2012 13:58, schrieb Joachim Schmitz: ++ mkdir failing

Re: [PATCH] Make test output coloring more intuitive

On 09/17/2012 10:11 PM, Jeff King wrote: On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote: The end result of these changes is that: - red is _only_ used for things which have gone unexpectedly wrong: test failures, unexpected test passes, and failures with the

Re: [PATCH] Make test output coloring more intuitive

On Wed, Sep 19, 2012 at 10:02:52PM +0200, Stefano Lattarini wrote: On 09/17/2012 10:11 PM, Jeff King wrote: On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote: The end result of these changes is that: - red is _only_ used for things which have gone unexpectedly wrong:

Re: [PATCH] Make test output coloring more intuitive

On Wed, Sep 19, 2012 at 09:12:01PM +0100, Adam Spiers wrote: Sounds reasonable, and I think the new output looks nice. I notice that skipped tests are still in green. I wonder if they should be in yellow, too. What about blue instead? This would keep the colouring scheme more

Re: [PATCH] Make test output coloring more intuitive

On Mon, Sep 17, 2012 at 04:11:19PM -0400, Jeff King wrote: On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote: The end result of these changes is that: - red is _only_ used for things which have gone unexpectedly wrong: test failures, unexpected test passes, and failures

Re: [PATCH] Make test output coloring more intuitive

On Tue, Sep 18, 2012 at 10:59 PM, Jeff King p...@peff.net wrote: TODO is a special token[1] respected by TAP harnesses like prove. I'm not sure what practical impact it has, but it should probably remain. -Peff [1] http://testanything.org/wiki/index.php/TAP_specification#TODO_tests Thanks,

[PATCH] Make test output coloring more intuitive

1. Change the color of individual known breakages from bold green to bold yellow. This seems more appropriate when considering the universal traffic lights coloring scheme, where green conveys the impression that everything's OK, and amber that something's not quite right. 2.

Re: [PATCH] Make test output coloring more intuitive

Adam Spiers g...@adamspiers.org writes: 1. Change the color of individual known breakages from bold green to bold yellow. This seems more appropriate when considering the universal traffic lights coloring scheme, where green conveys the impression that everything's OK, and amber

UHCI: make test for ASUS motherboard more specific

Dec 15 16:06:25 2006 -0500 Committer: Greg Kroah-Hartman [EMAIL PROTECTED] CommitDate: Fri Jan 5 12:19:08 2007 -0800 UHCI: make test for ASUS motherboard more specific Instead of matching all motherboards whose name contains A7V8X for a remote-wakeup hardware bug, this patch (as829