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

On Tuesday, July 02, 2013 03:24:14 am Michael Haggerty 
wrote:

quoted

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