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
Jeff King writes:
> Sometimes a breakage in pu is surprising (e.g., it breaks only on a
> platform that the maintainer does not run "make test" on) and we would
> want to know about it. But sometimes it is merely that there is a
> work-in-progress. And it probably requires a human to tell the
> d
For the record, that commit also sporadically breaks test 3910 on my
system (mentioning since it's not on the list)
On Tue, Feb 17, 2015 at 12:55 AM, Jeff King wrote:
> On Tue, Feb 17, 2015 at 09:39:17AM +0100, Dennis Kaarsemaker wrote:
>
>> Make test has been failing for 'pu' yesterday for and t
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 t
"Joachim Schmitz" schrieb im Newsbeitrag
news:...
> Hi folks
>
> I'm trying to understand why certain tests in 'make test' fail. Here's the
> first one
>
> $ ../git --version
> git version 1.8.0.rc2.5.g6b89306
> $ GIT_TEST_CMP_USE_COPIED_CONTEXT=true ./t-basic.sh # our diff doesn't
> unde
> 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"
> 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 bre
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
> #
> # mk
20 matches
Mail list logo
