On Wednesday, October 05, 2011 03:29:57 pm Michael Haggerty wrote: > My renovation of refs.c [1] is currently at 66 patches > and counting. What can I say?: (1) I like to make > changes in the smallest irreducible steps and (2) there > is a lot that needed to be done in refs.c. > > When I'm done, is it OK to dump a patch series like that > on the git mailing list? Is it pointless because nobody > will review them anyway? Is a big pile of changes like > this welcome in any form? Would it be better to convey > the changes via git itself (e.g., github) rather than > via emails? > > Michael > > [1] hierarchical-refs at git://github.com/mhagger/git.git Michael, I downloaded your patch series and tested it on my repos. Here are some of the timings I saw with your branch as is: * git clone 2:50m (same) * full fetch changes (> 1 hour) (bad!) * git branch (unpacked, ungced) .7s (good!) * git branch (packed, gced) .18s (~>same) * git checkout (unpacked, ungced) 10.5s (~>same) * git checkout (packed, gced) 9.5 (~>same) * noop fetch changes (unpacked, ungced) 14s (~>same) * noop fetch changes (packed, gced) 12s (same) For the full fetch, I estimated, things were scrolling by slow enough that after about 15 min I interrupted it. I suspect it might be at least 6 times longer (if rate stayed the same). Here are the best timings for all the good patches that others have submitted to fix many of the previous problems I brought up: * git clone 2:50m * full fetch changes 4:50m * git branch (unpacked, ungced) 9s * git branch (packed, gced) .05s * git checkout (unpacked, ungced) 9s * git checkout (packed, gced) 8s * noop fetch changes (unpacked, ungced) 12s * noop fetch changes (packed, gced) 12s (my internal patches bring full fetch down to 2:50m) It would be nice if you could rebase your work on top of some of the other patches also so that I could see those results. I might give that a try if I have the time and it is easy (or I might rebase those patches on yours). Thanks, -Martin -- Employee of Qualcomm Innovation Center, Inc. which is a member of Code Aurora Forum -- 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