Premature EOF repository error

[yilmazalican]

I have a Xcode project repository in gerrit which consisting of 11 GB. While cloning it with searchcode i encountering the error like: premature EOF repository. Does anybody encounter error like this? Should i edit the project to clone with ssh protocol? I've researched about this error and people suggest to shallow clone, but no support by jgit/egit. Thanks in advance

[boyter]

In this case I would suggest using native git. It tends to work more reliably, and the jgit that is in there is mostly to make it easier to drop install and get things running. For larger repositories this is generally not the best approach.

You can do so by setting use_system_git to true and then setting git_binary_path to the binary path.

Let me know how this works for you.

[yilmazalican]

Hello @boyter , thanks for replying. Even setting to use_system_git to true with a appropriate path, getting this error:

SEVERE: 6e56fa26::error in class class org.eclipse.jgit.api.errors.TransportException exception Premature EOF repository

Its it for Http, even when entering the ssh url while adding the repo but this time Auth error has been throwen. Setting this property to true is even makes no any improvement and while i clone the repo from the remote, i get same error by native git also in command interpreter. Is there any other approach to get rid of fetching all of the git history? Our repo is consisting of %80 size of .git folder especially the history.

[yilmazalican]

I have an idea, by using searchcode api. I want to write a script by python to schedule shallow clone and depth 1 fetches regularly to let searchcode index repos by native filesystem. What do you think of this idea?

[boyter]

Seems odd you are still getting a jgit error in this case though. Did you restart searchcode-server after making the use_system_git change? It will not hot reload so you need to restart (something I should look into fixing).

It is interesting that you get the same error with git command line.

What you have suggested would work. You could control the checkout/clone yourself and set searchcode-server to use native file system and index that. It would then update it based on file times and work as you would expect. Of course it means searchcode is no longer keeping the repository in sync for you but that might not be an issue.