Re: 66 patches and counting

[Martin Fick <mfick@codeaurora.org>]

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