Subject: Re: How to still kill git fetch with too many refs

From: Martin Fick <[email-masked]>
Date: Tue, 2 Jul 2013 10:58:58 -0600

On Tuesday, July 02, 2013 03:24:14 am Michael Haggerty 
wrote:
> > git rev-list HEAD | for nn in $(seq 0 100) ; do for c
> > in $(seq 0 10000) ; do  read sha ; echo $sha
> > refs/c/$nn/$c$nn ; done ; done > .git/packed-refs
> 
> I believe this generates a packed-refs file that is not
> sorted lexicographically by refname, whereas all
> Git-generated packed-refs files are sorted.  

Yes, you are indeed correct.  I was attempting to be too 
clever with my sharding I guess.  Thanks.

> There are
> some optimizations in refs.c for adding references in
> order that might therefore be circumvented by your
> unsorted file.  Please try sorting the file by refname
> and see if that helps.  (You can do so by deleting one
> of the packed references; then git will sort the
> remainder while rewriting the file.)

A simple git pack-refs seems to clean it up.

The original test did complete in ~77mins last night.  A 
rerun with a sorted file takes ~61mins,

-Martin

PS: This test was performed with git version 1.8.2.1 on 
linux 2.6.32-37-generic #81-Ubuntu SMP 

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation