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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
