summaryrefslogtreecommitdiff
path: root/t/t7505/expected-rebase-p
diff options
context:
space:
mode:
authorLibravatar Jonathan Tan <jonathantanmy@google.com>2020-04-27 17:01:09 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-04-28 09:55:02 -0700
commit4fa3f00abb55c3334cce71e201a5ff2c70f8561f (patch)
tree8cb45d844590a141325bf1822f2e5a285a24dc70 /t/t7505/expected-rebase-p
parentfetch-pack: return enum from process_acks() (diff)
downloadtgif-4fa3f00abb55c3334cce71e201a5ff2c70f8561f.tar.xz
fetch-pack: in protocol v2, in_vain only after ACK
When fetching, Git stops negotiation when it has sent at least MAX_IN_VAIN (which is 256) "have" lines without having any of them ACK-ed. But this is supposed to trigger only after the first ACK, as pack-protocol.txt says: However, the 256 limit *only* turns on in the canonical client implementation if we have received at least one "ACK %s continue" during a prior round. This helps to ensure that at least one common ancestor is found before we give up entirely. The code path for protocol v0 observes this, but not protocol v2, resulting in shorter negotiation rounds but significantly larger packfiles. Teach the code path for protocol v2 to check this criterion only after at least one ACK was received. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t7505/expected-rebase-p')
0 files changed, 0 insertions, 0 deletions