One assertion of this test checks for a shrinking cache tree. The
initial index contains a cache tree with two directory names but no
object ID, and the second index contains a cache tree with an object ID
but no directory name.
With SHA-1, the second index is smaller than the first, because the
Compute several object ID values instead of hard-coding them, and use
test_oid_to_path to cleanly produce a path for an object.
Note that the bisect code which is tested here remains sensitive to the
hash algorithm in use because it uses the object ID to disambiguate
between two equidistant commit
One assertion of this test checks for a shrinking cache tree. The
initial index contains a cache tree with two directory names but no
object ID, and the second index contains a cache tree with an object ID
but no directory name.
With SHA-1, the second index is smaller than the first, because the
Compute several object ID values instead of hard-coding them, and use
test_oid_to_path to cleanly produce a path for an object.
Note that the bisect code which is tested here remains sensitive to the
hash algorithm in use because it uses the object ID to disambiguate
between two equidistant commit
One assertion of this test checks for a shrinking cache tree. The
initial index contains a cache tree with two directory names but no
object ID, and the second index contains a cache tree with an object ID
but no directory name.
With SHA-1, the second index is smaller than the first, because the
Compute several object ID values instead of hard-coding them, and use
test_oid_to_path to cleanly produce a path for an object.
Note that the bisect code which is tested here remains sensitive to the
hash algorithm in use because it uses the object ID to disambiguate
between two equidistant commit
On Thu, Mar 07, 2019 at 12:35:58AM -0500, Jeffrey Walton wrote:
> I built Git 2.2.0 from sources. I added CFLAGS="-DNDEBUG -g2 -O1
> -fsantize=undefined'. Then, a 'make test V=1'. The tests don't produce
> output. For example:
>
> *** t0021-conversion.sh
Hi Everyone,
I built Git 2.2.0 from sources. I added CFLAGS="-DNDEBUG -g2 -O1
-fsantize=undefined'. Then, a 'make test V=1'. The tests don't produce
output. For example:
*** t0021-conversion.sh ***
ok 1 - setup
ok 2 - check
ok 3 - expanded_in_repo
ok 4 - filter she
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 for a week in
> 'n
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 pinging.
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
Thanks.
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, serv
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 (but mostly because
Todd Zullinger wrote:
> 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 daemon to be run (in t9
Developers can set GIT_TEST_SVNSERVE 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_POR
this while 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'
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 insta
ing 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
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 cause
ing 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'
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
offic
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 t/perf/p3400-rebase.sh
>
> diff --git a/t/per
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
new mode 100755
Ingo Brückl 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 colon, and a sentence that does n
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
---
t/t3700-add.sh
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 fu
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 resol
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 a
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 w/
criss-cross+contrived resolu
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
t6036-recu
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
>> 'test_set_editor' into each test.
>
> Wouldn't it be cl
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 contain:
1. using 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"
+write_script "check-for-diff" <<-\EOF &&
+grep '^diff --git' "$1" >o
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 its error reporting b
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 +3,11 @@
test_description='verbose commit t
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 the commit message.
>>> And, the justification is to make each test more s
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 self-contained,
>> particularly because a subsequent patch will
ests[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 this as primarily being about write_script(), but the
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 test sui
> 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 missing
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
--- a/t/t750
On Fri, Jun 12, 2015 at 5:43 PM, Jean-Yves LENHOF
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 privilegied user
ore in home file
ok 43 - erase: erase matching credentials from both xdg and home files
# failed 1 among 43 test(s)
1..43
make[2]: *** [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&
On 03/20, Junio C Hamano wrote:
> Thomas Gummerer 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
Thomas Gummerer 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
> ---
>> An updated patch to mention "when r
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
---
> An updated patch to mention "when run with TEST_GIT_INDEX_VERSION=4"
> in
Thomas Gummerer writes:
> On 03/20, Junio C Hamano wrote:
>> Thomas Gummerer 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 yo
On 03/20, Junio C Hamano wrote:
> Thomas Gummerer 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
>
Thomas Gummerer 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 "when run with inde
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/t1700-split-index.sh | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/
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 requir
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 '
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
>
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 quick
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.
>
&g
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
> #
> #
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 optimizatio
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 &&
# gi
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".
Soun
Jonathan Nieder 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
>> +++ b/t/t7501-commit.
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_succ
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.
Signed-off-
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.
Signed-off-
On Thu, Dec 20, 2012 at 7:21 PM, Junio C Hamano wrote:
> Jeff King 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,
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
Jeff King 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 patch 4/7
On Thu, Dec 20, 2012 at 4:11 PM, Jeff King 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
>> > p
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;;
On Thu, Dec 20, 2012 at 3:34 PM, Jeff King 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 wrote:
>> > Adam Spiers writes:
>> >> This series of commits attempts to make test output
On Sun, Dec 16, 2012 at 07:01:56PM +, Adam Spiers wrote:
> On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano wrote:
> > Adam Spiers writes:
> >
> >> This series of commits attempts to make test output coloring
> >> more intuitive,...
> >
> > Tha
Adam Spiers writes:
> On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano wrote:
>> Adam Spiers writes:
>>
>>> This series of commits attempts to make test output coloring
>>> more intuitive,...
>>
>> Thanks; I understand that this is to repl
On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano wrote:
> Adam Spiers 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 unexpected
Adam Spiers 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 is only
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 is
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 bas
> 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:
>
&g
# RFE 10-120912-4693 submitted to 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 /usr/local/bin i
> 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:
>
/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/diff,
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.
-
> 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:
>
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
> > > + S
> 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 wro
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/
top 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
"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_C
> 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...@linu
> 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:
> 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-c
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_m
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
> -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:
> > ...
> > +
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 =
> 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.
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"
1 - 100 of 115 matches
Mail list logo
