Hi, On Fri, 11 Jul 2008, Andreas Ericsson wrote: > Stephan Hennig wrote: > > Stephan Hennig schrieb: > > > > > I am observing very large data transfers when pulling from the > > > repository at <URL:http://repo.or.cz/w/wortliste.git>. > > > > Here's the output of a recent pull: > > > > > unknown@COMMODORE ~/Themen/trennmuster/repository/wortliste (master) > > > $ git pull > > > Enter passphrase for key '/x/home/.ssh/id_rsa': > > > remote: Counting objects: 15, done.←[K > > > remote: Compressing objects: 100% (7/7), done.←[K) ←[Kts: 8% (1/12) > > > remote: Total 12 (delta 5), reused 12 (delta 5)←[K > > > Unpacking objects: 100% (12/12), done. > > > From git+ssh://xxx@xxxxxxxxxx/srv/git/wortliste > > > d905095..d0c6a33 master -> origin/master > > > * [new tag] dehyph-exptl-v0.13 -> dehyph-exptl-v0.13 > > > Updating d905095..d0c6a33 > > > Fast forward > > > wortliste←[m | 19 ←[32m+++++++++++←[m←[31m--------←[m > > > 1 files changed, 11 insertions(+), 8 deletions(-)←[m > > > > After the line containing "remote: Compressing objects:" had been > > printed several MB have been transferred. > > > > Seems like you're being bitten by a bug we had some months back, > where the client requested full history for new tag objects. I do not think so. I think it is a problem with the pack. The slowness is already there in the clone, in the resolving phase. Judging from the output of "verify-pack -v", it seems that the delta chains are quite long. I saw memory usage go up pretty quickly. I thought that maybe eac12e2(Correct pack memory leak causing git gc to try to exceed ulimit) would help things, since it fixes a place where memory usage grows out of bounds, but it did not. Unfortunately, I do not have time to look into this further. BTW there is a nasty usability bug when "Compressing objects:" and "Receiving objects:" messages Ciao, Dscho