summaryrefslogtreecommitdiff
path: root/t/t4018
diff options
context:
space:
mode:
authorLibravatar SZEDER Gábor <szeder.dev@gmail.com>2019-11-19 02:25:25 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-11-20 10:30:18 +0900
commitbae60ba7e98dc57cbf291407491ab8fc80c5e2f4 (patch)
tree34064521a855a01ddfabc85465b9ecd1f82ab5bf /t/t4018
parentGit 2.23 (diff)
downloadtgif-bae60ba7e98dc57cbf291407491ab8fc80c5e2f4.tar.xz
builtin/unpack-objects.c: show throughput progress
'git unpack-objects' shows a progress line only counting the number of unpacked objects, so if some of the received objects are unusually large, then that progress might appear to be frozen while processing such a larger object. I just stared at a seemingly stuck progress line for over half a minute, while 'git fetch' was busy receiving a pack with only a couple of objects (i.e. fewer than 'fetch.unpackLimit'), with one of them being over 80MB. Display throughput in 'git unpack-objects' progress line, so we show that something is going on even when receiving and processing a large object. Counting the consumed bytes is far away from the place that counts objects and displays progress, and to pass around the 'struct progress' instance we would have to modify the signature of five functions and 14 of their callsites: this is just too much churn, so let's rather make it file-scope static. 'git index-pack', i.e. the non-unpacking cousin of 'git unpack-objects' already includes throughput in its progress line, and it uses a file-scope static 'struct progress' instance as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4018')
0 files changed, 0 insertions, 0 deletions