Do these (and I think we saw other reports) make us rethink the status of protocol v2 as the default? Are all of these fallouts we saw so far easy-to-fix bugs, or are there more fundamental issues in the v2 protocol design? Thanks. Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> writes: > On Wed, Apr 15, 2020 at 10:01:46AM +0200, Jiri Slaby wrote: >> Hi, >> >> I was at 8f3d9f354286 of: >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> >> I did git remote update today and it fetched: >> Receiving objects: 100% (7330823/7330823), 1.20 GiB >> It updated master: 8f3d9f354286..8632e9b5645b, that is 24 small commits. >> >> One colleague of mine fetched 1324 commits: >> Receiving objects: 100% (6820/6820), 4.21 MiB | 6.70 MiB/s, done. >> Resolving deltas: 100% (5114/5114), completed with 1035 local objects. >> From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux >> 7e63420847ae..8632e9b5645b master -> origin/master >> >> Another colleague fetched the same what I and: >> Receiving objects: 100% (7330823/7330823), 1.20 GiB >> too. >> >> I did git gc --prune && git prune now and I am at 1.7G back from 3.5 G. >> >> Is that a bug? What info should I provide? > > I've helped sfr troubleshoot the same issue last week -- it's most > likely due to 2.26 turning on protocol version=2 by default. > Unfortunately, reproducing this has been tricky, so if you can reliably > make this happen again, then providing a full copy of your local tree as > well as the remote you're trying to fetch may greatly help narrow it > down. > > With sfr (for whom fetching 1.2G from .au is a bit of a big deal), we > solved it by forcing protocol.version=1. > > -K
