* Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > > should i pack on both repos? I dont explicitly pack anything, but on > > the server it goes into regular gc runs. (which will pack most > > stuff, right?) > > git-gc automatically runs `git pack-refs --all --prune` like I > recommended, unless you disabled it with config gc.packrefs = false. > So its probably already packed. > > What does `find .git/refs -type f | wc -l` give for the repository on > the central server? If its more than a handful (~20) I would suggest > running git-gc before testing again. ah, you are right, it gave 275, then git-gc brought it down to two: earth4:~/tip> find .git/refs -type f | wc -l 275 earth4:~/tip> git gc earth4:~/tip> find .git/refs -type f | wc -l 2 i turned off auto-gc recently (two weeks ago) because it was auto-triggering _way_ too frequently. (like on every fifth merge i was doing or so) alas, fetching still seems to be slow: titan:~/tip> time git-fetch origin real 0m5.112s user 0m0.972s sys 0m3.380s (but the gc run has not finished yet on the central repo so this isnt fully valid.) > But I'm really suspecting that this is just our quadratic matching > algorithm running up against a large number of branches, causing it to > suck. > > jgit at least uses an O(N) algorithm here, but since it is written in > Java its of course slow compared to C Git. Takes a while to get that > JVM running. > > I'll try to find some time to reproduce the issue and look at the > bottleneck here. I'm two days into a new job so my git time has been > really quite short this week. :-| fetching the -tip repo: http://people.redhat.com/mingo/tip.git/README and then running 'git remote update' will i think already show this problem for you too. People have been complaining about how slow the update is. Ingo -- 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
