]> git.ipfire.org Git - thirdparty/git.git/commit - fetch-pack.c
transfer.unpackLimit: fetch/receive.unpackLimit takes precedence
authorJunio C Hamano <gitster@pobox.com>
Wed, 23 Aug 2023 01:30:21 +0000 (18:30 -0700)
committerJunio C Hamano <gitster@pobox.com>
Wed, 23 Aug 2023 01:30:49 +0000 (18:30 -0700)
commitf3d33f8cfeac8a2a00b4f87eec48dbca1d3080e0
treed2b708dd096959cfbbe9998d73cc1a2a87373faa
parentfb7d80edcae482f4fa5d4be0227dc3054734e5f3
transfer.unpackLimit: fetch/receive.unpackLimit takes precedence

The transfer.unpackLimit configuration variable is documented to be
used only as a fallback value when the more operation-specific
fetch.unpackLimit and receive.unpackLimit variables are not set, but
the implementation had the precedence reversed.  Apparently this was
broken since the transfer.unpackLimit was introduced in e28714c5
(Consolidate {receive,fetch}.unpackLimit, 2007-01-24).

Often when documentation and code have diverged for so long, we
prefer to change the documentation instead, to avoid disrupting
users.  But doing so would make these weirdly unlike most other
"specific overrides general" config options. And the fact that the
bug has existed for so long without anyone noticing implies to me
that nobody really tries to mix and match them much.

Signed-off-by: Taylor Santiago <taylorsantiago@google.com>
[jc: rewrote the log message, added tests, covered receive-pack as well]
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/receive-pack.c
fetch-pack.c
t/t5510-fetch.sh
t/t5546-receive-limits.sh