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.
Does this bug still show up if you use the latest git from
master of git.git?
I *think* v1.5.4.3-440-g41fa7d2 fixed the issue, but I'm
not 100% certain as the commit message doesn't mention anything
about any bugs being solved. Otoh, I vaguely remember the first
bug-reporter being told to try 'next', and afair, that solved it
for him/her.
Does it matter that the original clone has been performed with plain git
protocol? I have only later changed the url in .git/config to use git+ssh.
No, that doesn't matter in the slightest.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
