I've got a git repository I use to manage a set of RPMs. It's got history
stretching back for years, and imported nicely into git. Since it's used
to create RPMs, the repository has a structure similar to this:
.
|--README
|-- foo
| |--SOURCES
| | |--foo.tar.bz2
| | `--foo-build.patch
| `--SPECS
| `--foo.spec
`-- bar
|--SOURCES
| |--bar.tar.bz2
| `--bar-build.patch
`--SPECS
`--bar.spec
The source tarballs are updated when there's a new version of the
software; I don't need to worry about changes that are /inside/ the
tarball-- just that the tarball itself has changed. As you can imagine, a
fair amount of the 'stuff' in the repository are these binary tarballs.
The total repository size (ie. the '.git' folder): 4GB
I have only one complaint (and I can work around it anyway): I can't 'git
clone' the repository.
if I run:
git clone git://my.server.net/git/rpms
I get the following output:
remote: Generating pack...
remote: Done counting 20971 objects.
remote: Deltifying 20971 objects.
remote: 100% (20971/20971) done
3707.885MB (21657 kB/s)
remote: Total 20971, written 20971 (delta 9604), reused 20971 (delta 9604)
error: git-fetch-pack: unable to read from git-index-pack
error: git-index-pack died of signal 11
fetch-pack from 'git://my.server.net/git/rpms' failed.
It's interesting to note that during the pack file transfer, it stops
incrementing at ~3700 MB; the pack file is 4.0 GB. So either 300MB isn't
being transferred, or it's just not updating the display for the last few
hundred megs.
My workaround is to just use 'rsync' to copy the data (although scp works
too), then checkout the working copy. After that, fetch/pull and push
work fine.
The behavior is consistent with git v1.4.1 and v1.4.2, on SLES 9, SLES 10,
RHEL 4, and Gentoo.
It is also consistent if I clone via the git daemon, or the ssh protocol
('git clone server:/path/to/repo')
I originally had everything as loose objects. I then ran 'git-repack -d'
on occasion, so I had a combination of a large pack file, smaller pack
files, and loose objects. Finally, I tried 'git repack -a -d' and
consolidated it all into a single 4GB pack file. It didn't seem to make
much difference in the output.
Am I bumping some sort of limitation within git, or have I uncovered a bug?
--
Troy Telford
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html