[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] egit repository problem
|
On Fri, Jul 1, 2011 at 15:40, Matthias Sohn
<matthias.sohn@xxxxxxxxxxxxxx> wrote:
> The EGit Hudson CI build reports possible repository corruption [1]:
>
> Cloning repository origin
> $ git clone -o origin git://egit.eclipse.org/egit.git
> /opt/users/hudsonbuild/.hudson/jobs/egit.gerrit/workspace
>
> ERROR: Error cloning remote repo 'origin' : Could not clone
> git://egit.eclipse.org/egit.git
> ERROR: Cause: Error performing git clone -o origin
> git://egit.eclipse.org/egit.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 egit.eclipse.org 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
egit.eclipse.org or repack the repostiory. (Or both)
--
Shawn.
