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
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æ
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
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
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,
--
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
---
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
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
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
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,
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
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
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
>>
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
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"
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
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
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
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
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
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
> 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
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
---
]: *** [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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
+++
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. ;-)
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
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.
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.
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--
--- 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
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
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
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
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
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
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
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
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
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
+
-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
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
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
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
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
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
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:
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
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
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,
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.
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
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
99 matches
Mail list logo