From: Jeff King <peff@peff.net>
Date: Wed, 24 Aug 2016 18:54:28 GMT
Subject: Re: [PATCH v3 3/3] receive-pack: allow a maximum input size to be specified
Message-ID: <20160824185428.6k6tatv4cc5pre5c@sigill.intra.peff.net>
In-Reply-To: <20160824184157.19264-4-chriscool@tuxfamily.org>

On Wed, Aug 24, 2016 at 08:41:57PM +0200, Christian Couder wrote:

> +test_pack_input_limit () {
> +	case "$1" in
> +	index) unpack_limit=1 ;;
> +	unpack) unpack_limit=10000 ;;
> +	esac

Nice, this is pretty self-explanatory.

> +	test_expect_success 'prepare destination repository' '
> +		rm -fr dest &&
> +		git --bare init dest
> +	'
> +
> +	test_expect_success "set unpacklimit to $unpack_limit" '
> +		git --git-dir=dest config receive.unpacklimit "$unpack_limit"
> +	'
> +
> +	test_expect_success 'setting receive.maxInputSize to 512 rejects push' '
> +		git --git-dir=dest config receive.maxInputSize 512 &&
> +		test_must_fail git push dest HEAD
> +	'
> +
> +	test_expect_success 'bumping limit to 4k allows push' '
> +		git --git-dir=dest config receive.maxInputSize 4k &&
> +		git push dest HEAD
> +	'

Makes sense. We couldn't push, and then we could.

> +	test_expect_success 'prepare destination repository (again)' '
> +		rm -fr dest &&
> +		git --bare init dest
> +	'
> +
> +	test_expect_success 'lifting the limit allows push' '
> +		git --git-dir=dest config receive.maxInputSize 0 &&
> +		git push dest HEAD
> +	'

This is new in this iteration, I think. At first I thought "but every
_other_ test script is implicitly testing that we work without the
limit". But this is showing that setting the limit explicitly to 0 does
work, which is good.

The whole series looks fine to me.

-Peff