Re: [PATCH] t1404: increase core.packedRefsTimeout to avoid occasional test failure

On Wed, Aug 1, 2018 at 1:39 AM Jonathan Nieder wrote: > SZEDER Gábor wrote: > > > While 3secs timeout seems plenty, and indeed is sufficient in most > > cases, on rare occasions it's just not quite enough: I saw this test > > fail in Travis CI build jobs two, maybe three times because 'git > >

Re: [PATCH] t1404: increase core.packedRefsTimeout to avoid occasional test failure

Hi, SZEDER Gábor wrote: > While 3secs timeout seems plenty, and indeed is sufficient in most > cases, on rare occasions it's just not quite enough: I saw this test > fail in Travis CI build jobs two, maybe three times because 'git > update-ref' timed out. I suspect these tests will fail with

[PATCH] t1404: increase core.packedRefsTimeout to avoid occasional test failure

The test 'no bogus intermediate values during delete' in 't1404-update-ref-errors.sh', added in 6a2a7736d8 (t1404: demonstrate two problems with reference transactions, 2017-09-08), tries to catch undesirable side effects of deleting a ref, both loose and packed, in a transaction. To do so it is

[PATCH 3/4] subtree: fix a test failure under GETTEXT_POISON

Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t7900-subtree.sh | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/t/t7900-subtree.sh b/t/t7900-subtree.sh index eb223ff049..a6e7103f92 100755 --- a/t/t7900-subtree.sh +++ b/t/t7900-subtree.sh @@ -38,6

Re: Test failure for v2.16.0-rc0 on cygwin

On 04/01/18 20:55, Johannes Schindelin wrote: > On Tue, 2 Jan 2018, Ramsay Jones wrote: [snip] >> Also, when logged-in remotely it fails consistently, when logged-in >> directly it passes consistently. :-D > > You are most likely hitting cmd.exe at some point there. In cmd.exe, there > are some

Re: Test failure for v2.16.0-rc0 on cygwin

Hi, On Tue, 2 Jan 2018, Ramsay Jones wrote: > On 02/01/18 15:32, Ramsay Jones wrote: > > On 02/01/18 11:36, Adam Dinwoodie wrote: > >> On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote: > >>> On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote: > [snip] > >> I'm

Re: Test failure for v2.16.0-rc0 on cygwin

On 02/01/18 15:32, Ramsay Jones wrote: > On 02/01/18 11:36, Adam Dinwoodie wrote: >> On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote: >>> On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote: [snip] >> I'm not able to reproduce this: t5580 is passing on both my

Re: Test failure for v2.16.0-rc0 on cygwin

On 02/01/18 11:36, Adam Dinwoodie wrote: > On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote: >> On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote: >>> Hi Junio, Adam, >>> >>> Just a quick note about the failure of the test-suite on cygwin. >>> In particular,

Re: Test failure for v2.16.0-rc0 on cygwin

On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote: > On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote: > > Hi Junio, Adam, > > > > Just a quick note about the failure of the test-suite on cygwin. > > In particular, test t5580-clone-push-unc.sh #3, like so: > >

Re: Test failure for v2.16.0-rc0 on cygwin

On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote: > Hi Junio, Adam, > > Just a quick note about the failure of the test-suite on cygwin. > In particular, test t5580-clone-push-unc.sh #3, like so: > > > > Adam, are you running the tests on Windows 10? I'm only routinely

Test failure for v2.16.0-rc0 on cygwin

Hi Junio, Adam, Just a quick note about the failure of the test-suite on cygwin. In particular, test t5580-clone-push-unc.sh #3, like so: $ ./t5580-clone-push-unc.sh -i -v ... ok 2 - clone expecting success: ( cd clone && git checkout -b

Re: v2.15.0-rc1 test failure

On Thu, Oct 12, 2017 at 01:27:57AM +0100, Ramsay Jones wrote: > On 11/10/17 23:34, Adam Dinwoodie wrote: > [snip] > > Hi Ramsay, > > > > I assume, given you're emailing me, that this is a Cygwin failure? > > Yes, sorry, I should have made that clear. > > > t0021.15 has PERL as a requirement,

Re: v2.15.0-rc1 test failure

On 11/10/17 23:34, Adam Dinwoodie wrote: [snip] > Hi Ramsay, > > I assume, given you're emailing me, that this is a Cygwin failure? Yes, sorry, I should have made that clear. > t0021.15 has PERL as a requirement, and I see semi-regular failures from > Git tests that are Perl-based in one way

Re: v2.15.0-rc1 test failure

Hi, Adam Dinwoodie wrote: > t0021.15 has PERL as a requirement, and I see semi-regular failures from > Git tests that are Perl-based in one way or another (git-svn tests are > the most common problems). I've not spotted t0021 failing in that way, > but it sounds like the same class of problem.

Re: v2.15.0-rc1 test failure

On Wed, Oct 11, 2017 at 11:15:57PM +0100, Ramsay Jones wrote: > Hi Adam, > > I had a test failure on the v2.15.0-rc1 build tonight. > The test in question being t0021-conversion.sh #15 > ('required process filter should filter data'). I didn't > have any test failures on v2.15.

Re: v2.15.0-rc1 test failure

On 11/10/17 23:15, Ramsay Jones wrote: > Hi Adam, > > I had a test failure on the v2.15.0-rc1 build tonight. > The test in question being t0021-conversion.sh #15 > ('required process filter should filter data'). I didn't > have any test failures on v2.15.0-rc0, and I don'

v2.15.0-rc1 test failure

Hi Adam, I had a test failure on the v2.15.0-rc1 build tonight. The test in question being t0021-conversion.sh #15 ('required process filter should filter data'). I didn't have any test failures on v2.15.0-rc0, and I don't see any change that would have affected this test. Also, I ran this test

Re: mk-dontmerge/size-t-on-next test failure

Johannes Sixt <j...@kdbg.org> writes: > I observe the test failure below in t0040-parse-options.sh. It bisects > to 1a7909b25eb4ab3071ce4290115618e2582eadaa "Convert pack-objects to > size_t". It looks like git_parse_size_t() needs a fix. This is on > Windows, 32 bit.

mk-dontmerge/size-t-on-next test failure

I observe the test failure below in t0040-parse-options.sh. It bisects to 1a7909b25eb4ab3071ce4290115618e2582eadaa "Convert pack-objects to size_t". It looks like git_parse_size_t() needs a fix. This is on Windows, 32 bit. size_t, int and long are all 32 bits wide. expecti

Re: t6134 test failure in 'pu'

Thanks for a quick report. Yes, that was a stupid mismerge. Will correct in my rerere database X-<.

t6134 test failure in 'pu'

Hi Junio, t6134 fails for me in 'pu', but I think it is just a question of merge 641f3ad90a3 dropping the last line of the test from the change introduced by commit bdab972153. In other words, this fixes the test for me: $ git diff diff --git a/t/t6134-pathspec-in-submodule.sh

Re: test failure

> On 17 Dec 2016, at 15:28, Lars Schneider wrote: > > >> On 16 Dec 2016, at 21:32, Ramsay Jones wrote: >> >> Hi Lars, >> >> For the last two days, I've noticed t0021.15 on the 'pu' branch has been >> failing intermittently (well it

Re: test failure

> On 16 Dec 2016, at 21:32, Ramsay Jones wrote: > > Hi Lars, > > For the last two days, I've noticed t0021.15 on the 'pu' branch has been > failing intermittently (well it fails with: 'make test >ptest-out', but > when run by hand, it fails only say 1-in-6,

test failure

Hi Lars, For the last two days, I've noticed t0021.15 on the 'pu' branch has been failing intermittently (well it fails with: 'make test >ptest-out', but when run by hand, it fails only say 1-in-6, 1-in-18, etc.). [yes, it's a bit strange; this hasn't changed in a couple of weeks!] I don't

Re: [PATCH] t3700-add.sh: Avoid filename collission between tests which could lead to test failure

> On Oct 10, 2016, at 09:44, Junio C Hamano wrote: > > Jeremy Huddleston Sequoia writes: > >> Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c >> Signed-off-by: Jeremy Huddleston Sequoia >> CC: Thomas Gummerer

Re: [PATCH] t3700-add.sh: Avoid filename collission between tests which could lead to test failure

Jeremy Huddleston Sequoia writes: > Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c > Signed-off-by: Jeremy Huddleston Sequoia > CC: Thomas Gummerer > CC: Junio C Hamano This is also under-explained. Was

[PATCH] t3700-add.sh: Avoid filename collission between tests which could lead to test failure

Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c Signed-off-by: Jeremy Huddleston Sequoia CC: Thomas Gummerer CC: Junio C Hamano --- t/t3700-add.sh | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

Re: t7610-mergetool.sh test failure

On Wed, Jun 22, 2016 at 06:53:40PM +0200, Armin Kunaschik wrote: > Another thread I'm trying to revive... the discussion went away quite a bit > from the suggested patch to conditionally run this one test only when mktemp > is available. > > I'll create a patch when there are chances it is

Re: t7610-mergetool.sh test failure

Another thread I'm trying to revive... the discussion went away quite a bit from the suggested patch to conditionally run this one test only when mktemp is available. I'll create a patch when there are chances it is accepted. I could think of a way to replace mktemp with a perl one-liner (or

Re: t7610-mergetool.sh test failure

On Fri, May 27, 2016 at 12:58:15PM -0700, Junio C Hamano wrote: > On Fri, May 27, 2016 at 11:24 AM, Jeff King wrote: > > Which perhaps shows that maybe some people would > > see a performance regression if we moved from /tmp to a slower > > filesystem (e.g., especially people

Re: t7610-mergetool.sh test failure

On Fri, May 27, 2016 at 11:24 AM, Jeff King wrote: > Which perhaps shows that maybe some people would > see a performance regression if we moved from /tmp to a slower > filesystem (e.g., especially people whose git clone is on NFS or > something). Yup, but they would be using

Re: t7610-mergetool.sh test failure

On Thu, May 26, 2016 at 11:33:27PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The only one I can think of is that if something leaves cruft in > > $TMPDIR, it could affect later tests that want to `git add` > > indiscriminately. > > Or "git ls-files -u", "git clean",

Re: t7800 test failure

David Aguilar writes: > Another alternative is that we can compile our own > "git-readlink" and "git-mktemp" programs and use those instead, > but that seems like a big maintenance burden compared to the > relative simplicity of the test-suite workarounds. Not _that_ big

Re: t7610-mergetool.sh test failure

Jeff King writes: > The only one I can think of is that if something leaves cruft in > $TMPDIR, it could affect later tests that want to `git add` > indiscriminately. Or "git ls-files -u", "git clean", etc. I'd mostly worry about a failed test in which a program dies without a

Re: t7610-mergetool.sh test failure

On Thu, May 26, 2016 at 09:40:27PM -0700, David Aguilar wrote: > > BTW, one thing I happened to note while looking at this: running the > > test script will write into /tmp (or wherever your $TMPDIR points). > > Probably not a big deal, but I wonder if we should be setting $TMPDIR in > > our test

Re: t7610-mergetool.sh test failure

On Wed, May 25, 2016 at 08:51:14PM -0500, Jeff King wrote: > On Wed, May 25, 2016 at 06:16:15PM -0500, Jeff King wrote: > > > On Tue, May 24, 2016 at 09:45:25AM -0700, Junio C Hamano wrote: > > > > > On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik > > > wrote: > > > >

Re: t7800 test failure

On Wed, May 25, 2016 at 11:33:33AM +0200, Armin Kunaschik wrote: > On Tue, May 24, 2016 at 7:36 PM, Junio C Hamano wrote: > > Armin Kunaschik writes: > >> > >> Ok, how can this be implemented within the test environment? > > > > I actually think an

Re: t7610-mergetool.sh test failure

On Wed, May 25, 2016 at 06:16:15PM -0500, Jeff King wrote: > On Tue, May 24, 2016 at 09:45:25AM -0700, Junio C Hamano wrote: > > > On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik > > wrote: > > > t7610-mergetool.sh fails on systems without mktemp. > > > > > > mktemp

Re: t7610-mergetool.sh test failure

On Tue, May 24, 2016 at 09:45:25AM -0700, Junio C Hamano wrote: > On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik > wrote: > > t7610-mergetool.sh fails on systems without mktemp. > > > > mktemp is used in git-mergetool.sh and throws an error when it's not > >

Re: t7800 test failure

On Tue, May 24, 2016 at 7:36 PM, Junio C Hamano wrote: > Armin Kunaschik writes: >> >> Ok, how can this be implemented within the test environment? > > I actually think an unconditional check like this is sufficient. Ah, good. My thoughts were a bit

Re: t7800 test failure

Armin Kunaschik writes: >> I wouldn't allow it in our scripted Porcelain, but the environment >> of our test scripts are under our control, so I do not think it is a >> problem ("ls piped to sed" has been an established idiom before >> readlink(1) was widely accepted,

Re: t7800 test failure

On Tue, May 24, 2016 at 6:57 PM, Junio C Hamano wrote: > Matthieu Moy writes: > >> Armin Kunaschik writes: >> >>> t7800 fails on systems where readlink (GNUism?) is not available. >> >> I don't think it's POSIX, but it

Re: t7800 test failure

Matthieu Moy writes: > Armin Kunaschik writes: > >> t7800 fails on systems where readlink (GNUism?) is not available. > > I don't think it's POSIX, but it is present on all POSIX-like systems I > know. On which system did you get the

Re: t7610-mergetool.sh test failure

On Tue, May 24, 2016 at 6:45 PM, Junio C Hamano wrote: > 3. find and install mktemp? Sure, but which one? :-) mktemp is not mentioned in POSIX. http://stackoverflow.com/questions/2792675/how-portable-is-mktemp1 -- To unsubscribe from this list: send the line "unsubscribe git"

Re: t7800 test failure

Armin Kunaschik writes: > t7800 fails on systems where readlink (GNUism?) is not available. I don't think it's POSIX, but it is present on all POSIX-like systems I know. On which system did you get the issue? > +readlink() { ls -ld "$1" | sed 's/.* -> //'; } This is

Re: t7610-mergetool.sh test failure

On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik wrote: > t7610-mergetool.sh fails on systems without mktemp. > > mktemp is used in git-mergetool.sh and throws an error when it's not > available. > error: mktemp is needed when 'mergetool.writeToTemp' is true > > I see 2

t7610-mergetool.sh test failure

t7610-mergetool.sh fails on systems without mktemp. mktemp is used in git-mergetool.sh and throws an error when it's not available. error: mktemp is needed when 'mergetool.writeToTemp' is true I see 2 options: 1. code around it, write an own mktemp, maybe use the test-mktemp as a basis. 2.

t7800 test failure

t7800 fails on systems where readlink (GNUism?) is not available. An easy workaround for the very basic readlink usage of this test would be to use a shell function like this: --- diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh index ff7a9e9..be3d19f 100755 --- a/t/t7800-difftool.sh +++

t7063-status-untracked-cache.sh test failure on next

Hi Junio, While testing the next branch today, I had a test failure, viz: $ tail ntest-out-fail Test Summary Report --- t7063-status-untracked-cache.sh (Wstat: 256 Tests: 32 Failed: 22) Failed tests: 1-18, 20-21, 25, 29 Non-zero exit

Re: t7063-status-untracked-cache.sh test failure on next

On 21.10.15 16:37, Ramsay Jones wrote: > Hi Junio, > > While testing the next branch today, I had a test failure, viz: > > $ tail ntest-out-fail > Test Summary Report > --- > t7063-status-untracked-cache.sh (Wstat: 256

Re: t7063-status-untracked-cache.sh test failure on next

On 21/10/15 17:05, Torsten Bögershausen wrote: > On 21.10.15 16:37, Ramsay Jones wrote: >> Hi Junio, >> >> While testing the next branch today, I had a test failure, viz: >> >> $ tail ntest-out-fail >> Test Summary Report >> -

Re: t7063-status-untracked-cache.sh test failure on next

On Wed, 2015-10-21 at 18:05 +0200, Torsten Bögershausen wrote: > On 21.10.15 16:37, Ramsay Jones wrote: > > Hi Junio, > > > > While testing the next branch today, I had a test failure, viz: > > > > $ tail ntest-out-fail > > Test Summary Report &g

Re: t7063-status-untracked-cache.sh test failure on next

On 21/10/15 18:50, David Turner wrote: > On Wed, 2015-10-21 at 18:05 +0200, Torsten Bögershausen wrote: >> On 21.10.15 16:37, Ramsay Jones wrote: >>> Hi Junio, >>> >>> While testing the next branch today, I had a test failure, viz: >>> >>>

mac test failure -- 2gb clone

This is in pu, haven't checked if it's also in master, this is the first time I've run this test $ GIT_TEST_CLONE_2GB=t ./t5705-clone-2gb.sh -v Initialized empty Git repository in /Users/michael.blume/workspace/git/t/trash directory.t5705-clone-2gb/.git/ expecting success: git config

Re: mac test failure -- 2gb clone

Confirmed exists on master On Wed, Nov 12, 2014 at 1:57 PM, Michael Blume blume.m...@gmail.com wrote: This is in pu, haven't checked if it's also in master, this is the first time I've run this test $ GIT_TEST_CLONE_2GB=t ./t5705-clone-2gb.sh -v Initialized empty Git repository in

Re: mac test failure -- 2gb clone

On 2014-11-12 22.57, Michael Blume wrote: [t5705-clone-2gb.sh broken on Mac OS] It is most probably even broken on every platform, since we renovated the URL parser in 2013. (More info can be found here:) git log t/t5601-clone.sh I missed t5705-clone-2gb.sh, because it has its own enabler

Re: mac test failure -- test 3301

Johan Herland jo...@herland.net writes: Ah, thanks! I thought that quoting command output was a good idea in general. Am I wrong, or is this just one exception to an otherwise good guideline? It is not a good practice to blindly follow any guideline ;-). When you anticipate that different

Re: mac test failure -- test 3301

On Tue, Nov 11, 2014 at 3:41 AM, Jeff King p...@peff.net wrote: On Tue, Nov 11, 2014 at 02:40:19AM +0100, Johan Herland wrote: This and all other failures are due to the output of 'wc -l', which on Mac is {whitespace}1 rather than just 1 as it is on other platforms. fbe4f748 added quotes

mac test failure -- test 3301

the commit modernizing test 3301 (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it on my mac Verbose output follows: $ ./t3301-notes.sh -v Initialized empty Git repository in /Users/michael.blume/workspace/git/t/trash directory.t3301-notes/.git/ expecting success:

Re: mac test failure -- test 3301

(to be clear: I ran git bisect, and traced the problem to the modernize commit) On Mon, Nov 10, 2014 at 4:17 PM, Michael Blume blume.m...@gmail.com wrote: the commit modernizing test 3301 (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it on my mac Verbose output follows:

Re: mac test failure -- test 3301

my first thought was that this might be a bash versioning issue, since the commit in question basically refactors the script, and macs ship with an archaic version of bash, but I have the same problem with bash 4.3.30 On Mon, Nov 10, 2014 at 4:23 PM, Michael Blume blume.m...@gmail.com wrote: (to

Re: mac test failure -- test 3301

On Mon, Nov 10, 2014 at 7:17 PM, Michael Blume blume.m...@gmail.com wrote: the commit modernizing test 3301 (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it on my mac $ ./t3301-notes.sh -v expecting success: MSG=b4 git notes add test_path_is_missing

Re: mac test failure -- test 3301

On Tue, Nov 11, 2014 at 2:19 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Mon, Nov 10, 2014 at 7:17 PM, Michael Blume blume.m...@gmail.com wrote: the commit modernizing test 3301 (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it on my mac $ ./t3301-notes.sh -v

Re: mac test failure -- test 3301

If quoting is generally preferred as a best practice, we could force wc to behave more consistently before we start testing diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index 0d93e33..57ed608 100644 --- a/t/test-lib-functions.sh +++ b/t/test-lib-functions.sh @@ -515,6 +515,14 @@

Re: mac test failure -- test 3301

On Tue, Nov 11, 2014 at 02:40:19AM +0100, Johan Herland wrote: This and all other failures are due to the output of 'wc -l', which on Mac is {whitespace}1 rather than just 1 as it is on other platforms. fbe4f748 added quotes around the $(... | wc -l) invocation which caused the whitespace

Test failure

I'm on a macbook running a beta of Mac OS Yosemite 10.10.1. I've never been able to get GETTEXT to work so I have NO_GETTEXT=1 in my makefile, but other than that I'm using the master branch of the official github mirror. When I build and run tests I get

Re: Test failure

On Sat, Nov 08, 2014 at 11:28:32AM -0800, Michael Blume wrote: When I build and run tests I get [11:17][michael.blume@tcc-michael-4:~/workspace/git/t(master)]$ ./t1410-reflog.sh What does ./t1410-reflog.sh -v -i report? A quick search seems to indicate the test is pretty new?

Re: Test failure

$ ./t1410-reflog.sh -v -i Initialized empty Git repository in /Users/michael.blume/workspace/git/t/trash directory.t1410-reflog/.git/ expecting success: mkdir -p A/B echo rat C echo ox A/D echo tiger A/B/E git add . test_tick git commit -m rabbit H=`git rev-parse --verify HEAD` A=`git

t2017 test failure in pu

Hi Junio, The current 'pu' branch has a test failure for me, namely test t2017-checkout-orphan.sh #9. I had a quick squint at the conflict resolution in commit acdbdf99 and the only thing that seemed relevant was the dropping of the 'log_all_ref_updates' dance. So, I quickly put it back, like so

Re: [PATCH] git p4 test: fix failure in 9814-git-p4-rename.sh Was: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

On Thu, Jul 24, 2014 at 8:45 PM, Johannes Sixt j...@kdbg.org wrote: Am 23.07.2014 23:28, schrieb Christoph Bonitz: - test $src = file10 || test $src = file11 + test $src = file2 || test $src = file10 || test $src = file11 You can't test for alternatives in this way. It's already wrong in

Re: [PATCH] git p4 test: fix failure in 9814-git-p4-rename.sh Was: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

On Fri, Jul 25, 2014 at 12:05 AM, Junio C Hamano gits...@pobox.com wrote: Johannes Sixt j...@kdbg.org writes: I see a few other no-nos in the context of the changes, in particular, pipelines where git is not the last command; these would not catch failures in the git commands. But a fix for

Re: [PATCH] git p4 test: fix failure in 9814-git-p4-rename.sh Was: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

Christoph Bonitz ml.christophbon...@gmail.com writes: Apart from your change and the word wrap adjustments suggested by Pete, would the following also make sense, to fix the other flaw Johannes pointed out? With regards to failing, git diff-tree should be idempotent. I think those are the two

Re: [PATCH] git p4 test: fix failure in 9814-git-p4-rename.sh Was: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

Am 23.07.2014 23:28, schrieb Christoph Bonitz: The scenario in the rename test makes unnecessary assumptions about which file git file-tree will detect as a source for a copy-operations. Furthermore, copy detection is not tested by checking the resulting perforce revision history via p4

Re: [PATCH] git p4 test: fix failure in 9814-git-p4-rename.sh Was: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

Johannes Sixt j...@kdbg.org writes: @@ -177,7 +175,7 @@ test_expect_success 'detect copies' ' level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 | cut -d -f5 | sed s/C0*//) test -n $level test $level -gt 0 test $level -lt 98 src=$(git diff-tree -r -C

Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

On Mon, Jul 7, 2014 at 11:14 PM, Junio C Hamano gits...@pobox.com wrote: Choosing any of these as the copy source is fine is a sensible way to fix the problem with this test. Would it be a better solution to avoid having multiple/ambiguous copy source candidates in the first place, by the

[PATCH] git p4 test: fix failure in 9814-git-p4-rename.sh Was: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

Jul 2014 16:32 +0200: I'm trying to get the git p4 tests to pass on my machine (OS X Mavericks) from master before making some changes. I'm experiencing a test failure in detect copies of the rename test. The test creates file2 with some content, creates a few copies (each with a commit

Re: [PATCH] git p4 test: fix failure in 9814-git-p4-rename.sh Was: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

ml.christophbon...@gmail.com wrote on Wed, 23 Jul 2014 23:28 +0200: The scenario in the rename test makes unnecessary assumptions about which file git file-tree will detect as a source for a copy-operations. Furthermore, copy detection is not tested by checking the resulting perforce revision

Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

Pete Wyckoff p...@padd.com writes: I'm not sure how to robustify this. At least doing the multiple comparisons should make the tests work again. The goal of this series of tests is to make sure that copy detection is working, not to verify that the correct copy choice was made. That should

Test failure in t9814-git-p4-rename.sh - my environment or bad test?

Hi, I'm trying to get the git p4 tests to pass on my machine (OS X Mavericks) from master before making some changes. I'm experiencing a test failure in detect copies of the rename test. The test creates file2 with some content, creates a few copies (each with a commit), then does the following

Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?

ml.christophbon...@gmail.com wrote on Sun, 06 Jul 2014 16:32 +0200: I'm trying to get the git p4 tests to pass on my machine (OS X Mavericks) from master before making some changes. I'm experiencing a test failure in detect copies of the rename test. The test creates file2 with some content

Re: Git v1.8.4.2 test failure in ./t5570-git-daemon.sh

On Tue, Oct 29, 2013 at 06:12:58PM -0700, Junio C Hamano wrote: I think it was just a simple mixup caused by Brian sending two fixups to t5570 as series, when they are really fixups for two different topics. Not worth an immediate v1.8.4.3, I think, but you may want to cherry-pick 360a326

Re: Git v1.8.4.2 test failure in ./t5570-git-daemon.sh

Jeff King p...@peff.net writes: On Tue, Oct 29, 2013 at 01:54:31AM +0100, Simon Ruderich wrote: I just compiled Git v1.8.4.2 on Debian Wheezy amd64 and test t5570 fails (with GIT_TEST_GIT_DAEMON=1): [...] Bisecting leads to this commit: commit 68b939b2f097b6675c4aaa17869aa81b25cb

git test failure: t9903-bash-prompt.sh on darwin8

Hi, I'm seeing a test failure with git-1.8.4 on powerpc-darwin8: [11:00:56] t9903-bash-prompt.sh ... not ok 13 - prompt - interactive rebase not ok 14 - prompt - rebase merge Details here: http://paste.lisp.org/display/139525 The odd thing is that when I

Git v1.8.4.2 test failure in ./t5570-git-daemon.sh

Hello, I just compiled Git v1.8.4.2 on Debian Wheezy amd64 and test t5570 fails (with GIT_TEST_GIT_DAEMON=1): --- expect 2013-10-28 23:27:26.792409631 + +++ output 2013-10-28 23:27:26.788409614 + @@ -1 +1,2 @@ +Cloning into 'nowhere'... fatal: remote error:

Re: Git v1.8.4.2 test failure in ./t5570-git-daemon.sh

On Tue, Oct 29, 2013 at 01:54:31AM +0100, Simon Ruderich wrote: I just compiled Git v1.8.4.2 on Debian Wheezy amd64 and test t5570 fails (with GIT_TEST_GIT_DAEMON=1): [...] Bisecting leads to this commit: commit 68b939b2f097b6675c4aaa17869aa81b25cb Author: Jeff King

Re: Test failure: Test #3 in t1304-default-acl

Hi Junio, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: I haven't been paying attention, but does that mean on that system, a total stranger kseygold can write, modify, and remove whatever Ram owns? I am hoping that is not

Re: Test failure: Test #3 in t1304-default-acl

Ramkumar Ramachandra wrote: Hi Junio, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: I haven't been paying attention, but does that mean on that system, a total stranger kseygold can write, modify, and remove whatever Ram

Re: Test failure: Test #3 in t1304-default-acl

Ramkumar Ramachandra artag...@gmail.com writes: Hi Junio, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: I haven't been paying attention, but does that mean on that system, a total stranger kseygold can write, modify, and

Test failure: Test #3 in t1304-default-acl

Hi, The following test in t1304-default-acl.sh fails for me on the latest master: test_expect_success SETFACL 'Objects creation does not break ACLs with restrictive umask' ' # SHA1 for empty blob check_perms_and_acl .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 ' It

Re: Test failure: Test #3 in t1304-default-acl

Matthieu Moy matthieu@grenoble-inp.fr writes: Ramkumar Ramachandra artag...@gmail.com writes: Hi again, Matthieu Moy wrote: Does this user have the same UID as your usual user (id kseygold; id $LOGNAME)? Yes. What do you propose we do about the test? On a GNU system, something

Re: Test failure: Test #3 in t1304-default-acl

Matthieu Moy wrote: Junio C Hamano gits...@pobox.com writes: I haven't been paying attention, but does that mean on that system, a total stranger kseygold can write, modify, and remove whatever Ram owns? I am hoping that is not the case. I can see two reasons for having the same UID for two

Re: Test failure: Test #3 in t1304-default-acl

Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: I haven't been paying attention, but does that mean on that system, a total stranger kseygold can write, modify, and remove whatever Ram owns? I am hoping that is not the case. I can see two reasons

[PATCH 1/2] t1100-*.sh: Fix an intermittent test failure

In particular, the final test ('flags and then non flags') fails intermittently, depending on how much time elapsed between the invocations of git commit-tree when creating the commits which later have their commit id's compared. For example, if the commits for childid-3 and childid-4 are created