2008/9/16 Karl Hasselström : > On 2008-09-16 15:59:31 +0100, Catalin Marinas wrote: >> I think we could merge your experimental branch into master. I gave >> it a try and seems OK. The only issue I had was that I had an older >> version of Git and it failed in really weird ways (stg pop still >> busy-looping after 4 minutes and in another case it failed with >> broken pipe). Once I pulled the latest Git, it was fine but we >> should try to be compatible at least with the Git version in the >> Debian testing distribution. It might be the patch at the top with >> diff-ing several trees at once but I haven't checked. > > There are two patches that depend on new git versions. One needs git > 1.5.6, which is in testing so I'll be pushing that to you; OK. > the other > needs Junio's master branch, and i won't even consider asking you to > take it until it's in a released git. Correct :-) > I hope to push it out to you tonight or tomorrow, but I have a small > pet patch I'd like to finish first, so I might be late. OK, no problem. I won't have much time before the weekend anyway. >> BTW, I ran some benchmarks on stable/master/kha-experimental >> branches with 300 patches from the 2.6.27-rc5-mm1 kernel. See >> attached for the results. Since performance was my worry with the >> stack log stuff, it turns out that there isn't a big difference with >> real patches. I think pushing can be made even faster by trying a >> git-apply first and taking the diff from the saved blobs in the log. > > When benchmarking recent StGits, you'll want to try goto as well, > since push and pop are not yet new-infrastructure-ized (meaning > they're getting slowdowns from the stack log, but no speedups (if any) > from the new infrastructure). Indeed, goto is faster even than the stable branch. I attached the new figures. I think it could go even faster if pushing attempts a "git apply" first before the index merge. With the stack log, the patch diff should be saved already so no need for a "git diff" (as in the stable branch). -- Catalin