On Wed, Jan 14, 2009 at 12:58 AM, Dave Page <dpage@pgadmin.org> wrote:
> This happens on the local machine presumably? I used to suffer that
> problem and resolved it with 'ulimit -n 1024' in my bash profile.
This is because the number of packs in the git.postgresql.org repo is
enormous, which also slows down clones and many other git operations.
Try running "git gc --aggressive" to fix this on your local copy (this
will take a while -- probably hours -- unless you've done it before).
On the other hand, I've recorded a size difference in the pack going
from > 300 MB to ~100MB. Using a fresh clone from git.postgresql.org I
had to actually raise ulimit -n above 1024 to perform this operation,
or else I hit my open file limit. You should also notice a marked
improvement in the performance of certain operations.
From time to time I recommend running a regular 'git gc' to
consolidate packs. Newish versions of git feature automatically
triggered gc to do these things, precisely to avoid the kinds of
problems you describe. The setting "gc.autopacklimit" to determines
how many pack files are allowed. I don't know what the default is.
If you are especially impatient, you can clone the repository
mentioned previously (you will inherit the repacking I've already
done) and port your patches over using "git format-patch" and "git am"
or even just adding your old repository as a remote and fetching the
branches. You can then set the "origin" remote to git.postgresql.org
to continue getting updates from there.
fdr
