Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] egit repository problem

2011/7/2 Shawn Pearce <spearce@xxxxxxxxxxx>
On Fri, Jul 1, 2011 at 15:40, Matthias Sohn
> The EGit Hudson CI build reports possible repository corruption [1]:
> Cloning repository origin
> $ git clone -o origin git://
> /opt/users/hudsonbuild/.hudson/jobs/egit.gerrit/workspace
> ERROR: Error cloning remote repo 'origin' : Could not clone
> git://
> ERROR: Cause: Error performing git clone -o origin
> git://
> /opt/users/hudsonbuild/.hudson/jobs/egit.gerrit/workspace
> Command returned status code 128: Initialized empty Git repository in
> /opt/users/hudsonbuild/.hudson/jobs/egit.gerrit/workspace/.git/
> remote: aborting due to possible repository corruption on the remote side.
> fatal: error in sideband demultiplexer

Time to run `git fsck --full` on inside of the
egit.git repository.

I'll bet the problem is actually that the repository has a HUGE number
of pack files (due to Gerrit Code Review being used on it), hasn't
been repacked in a long time (because I forgot to repack it), and the
Git implementation on that box croaks when the number of pack files
exceeds the number of file descriptors the ulimit allows to be open at
once in a process. :-)

JGit can serve the repository just fine, we've long had file
descriptor handling in place. Newer C Gits can do this too (I fixed it
when Android had this problem). Either upgrade the Git version on or repack the repostiory. (Or both)

I tried repacking as described in [1] but this fails:

Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
fatal: object a87f1cf0116078ffab0a8bb4b56fbcf9ff9342e4 is corrupted
error: failed to run repack

[1]+  Exit 255                git gc --auto --aggressive --prune

It succeeded to pack the refs but we still have 1322 pack files. 


Back to the top