Re: 66 patches and counting
flat view
From: Martin Fick <hidden>
Date: 2016-06-15 22:52:12
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