Jeff King writes:
>> - We may want to do something similar in cvsserver and git-gui to
>>make them more robust.
>>
>>$ git grep -e true --and -e 1 --and -e yes
>
> I assume the "something" here is to respect bool options more
> consistently?
Yeah, mostly by employing your 'git -c magic
oo you have in your PATH. There is
nothing to run "by default" there. It would be sensible to hook
contrib/credential to it, though.
> -- >8 --
> From: Jeff King
> Date: Mon, 10 Feb 2014 16:29:37 -0500
> Subject: [PATCH] tests: turn on network daemon tests by default
>
o something similar to GIT_TEST_CREDENTIAL_HELPER?
-- >8 --
From: Jeff King
Date: Mon, 10 Feb 2014 16:29:37 -0500
Subject: [PATCH] tests: turn on network daemon tests by default
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network acces
On Thu, Feb 13, 2014 at 5:12 AM, Jeff King wrote:
> lib-httpd was never designed to be included from anywhere except the
> beginning of the file. But that wouldn't be right for t5537, because it
> wants to run some of the tests, even if apache setup fails. The right
> way to do it is probably to h
Jeff King writes:
> test_normalize_tristate GIT_TEST_DAEMON
Heh, great minds think alike. This is what I am playing with,
without committing (because I do like your "ask config if this is a
kind of various boolean 'false' representations, which I haven't
managed to add to it).
t/lib-git-da
On Wed, Feb 12, 2014 at 11:06:43AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Agreed, but I think the only way to know the size of those fallouts is
> > to try it and see who complains. I would not normally be so cavalier
> > with git itself, but I think for the test infrastructure,
On Tue, Feb 11, 2014 at 03:58:27PM -0800, Junio C Hamano wrote:
> Sure. One immediate complaint is that I would probably need to do
> something like this in the build automation:
>
> if testing a branch without this patch
> then
> : do nothing
> else
>
Jeff King writes:
> Agreed, but I think the only way to know the size of those fallouts is
> to try it and see who complains. I would not normally be so cavalier
> with git itself, but I think for the test infrastructure, we have a
> small, tech-savvy audience that can help us iterate on it with
Jeff King writes:
> On Tue, Feb 11, 2014 at 11:51:18AM -0800, Junio C Hamano wrote:
>
>> Those who run buildfarms may want to disable the networking test if
>> the buildfarms are not isolated well, for example. They have to be
>> told somewhere that now they need to explicitly disable these test
On Tue, Feb 11, 2014 at 11:51:18AM -0800, Junio C Hamano wrote:
> Those who run buildfarms may want to disable the networking test if
> the buildfarms are not isolated well, for example. They have to be
> told somewhere that now they need to explicitly disable these tests
> and how.
I think they
Jeff King writes:
> I dug in the history to see if there was any reasoning given for the
> current "off by default" setting. It looks like Junio asked for it when
> the original http-push tests were added, and everything else just
> followed that. The reasoning there was basically "they're heavyw
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network access
(albeit over localhost). However, it would be nice if more
pepole ran them, for two reasons:
1. We would get more test coverage on more systems.
2. The point of the test suite is
12 matches
Mail list logo