error - remote %s does not have %s

552 views
Skip to first unread message

Brad Larson

unread,
Oct 2, 2009, 5:29:22 PM10/2/09
to Repo and Gerrit Discussion
Occasionally I have users run into this error during a repo sync. Re-
running the repo sync always fixes the problem. Any thoughts or
suggestions?? We are currently syncing through gitosis, not gerrit -
this will change once we pull up to 2.0.22 next week.

Fetching projects: 100% (2/2), done.
Syncing work tree: 92% (151/164) Traceback (most recent call last):
File "/home/user/projects/.repo/repo/main.py", line 235, in <module>
_Main(sys.argv[1:])
File "/home/projects/.repo/repo/main.py", line 217, in _Main
repo._Run(argv)
File "/home/projects/.repo/repo/main.py", line 123, in _Run
cmd.Execute(copts, cargs)
File "/home/projects/.repo/repo/subcmds/sync.py", line 238, in
Execute
project.Sync_LocalHalf(syncbuf)
File "/home/projects/.repo/repo/project.py", line 642, in
Sync_LocalHalf
revid = self.GetRevisionId(all)
File "/home/projects/.repo/repo/project.py", line 622, in
GetRevisionId
rev = rem.ToLocal(self.revisionExpr)
File "/home/projects/.repo/repo/git_config.py", line 520, in ToLocal
raise GitError('remote %s does not have %s' % (self.name, rev))
error.GitError: remote company-mirror does not have refs/heads/master

Shawn Pearce

unread,
Oct 2, 2009, 5:33:59 PM10/2/09
to repo-d...@googlegroups.com
On Fri, Oct 2, 2009 at 14:29, Brad Larson <bkla...@gmail.com> wrote:
>
> Occasionally I have users run into this error during a repo sync.  Re-
> running the repo sync always fixes the problem.  Any thoughts or
> suggestions??  We are currently syncing through gitosis, not gerrit -
> this will change once we pull up to 2.0.22 next week.
....

> error.GitError: remote company-mirror does not have refs/heads/master

Not a clue. We've been using only git:// or gerrit SSH for sync and
haven't noticed this from either.

But I also wonder if it isn't a possible file system race condition.
For a while we were seeing lots of weird stuff like this on Mac OS X
HFS+ volumes when there was more than one CPU enabled, because HFS+
had data synchronization issues and sometimes the other core wouldn't
notice that a VFS change had taken place.

Brad Larson

unread,
Oct 20, 2009, 2:33:32 PM10/20/09
to Repo and Gerrit Discussion
This might be unrelated, but I ran into a problem today and found
server logs:

2009-10-20 11:33:17,798::ERROR:
com.google.gerrit.server.ssh.BaseCommand - Internal server error
(user johndoe account 1000015) during git-upload-pack '/platform/
repository.git'
java.lang.OutOfMemoryError: Java heap space
at org.spearce.jgit.lib.UnpackedObjectLoader.<init>
(UnpackedObjectLoader.java:130)
at org.spearce.jgit.lib.UnpackedObjectLoader.<init>
(UnpackedObjectLoader.java:76)
at org.spearce.jgit.lib.ObjectDirectory.openObject2
(ObjectDirectory.java:254)
at org.spearce.jgit.lib.ObjectDatabase.openObjectImpl2
(ObjectDatabase.java:231)
at org.spearce.jgit.lib.ObjectDatabase.openObject
(ObjectDatabase.java:196)
at org.spearce.jgit.lib.Repository.openObject(Repository.java:
274)
at org.spearce.jgit.lib.PackWriter.writeWholeObjectDeflate
(PackWriter.java:762)
at org.spearce.jgit.lib.PackWriter.writeObject(PackWriter.java:
732)
at org.spearce.jgit.lib.PackWriter.writeObjects
(PackWriter.java:692)
at org.spearce.jgit.lib.PackWriter.writePack(PackWriter.java:
592)
at org.spearce.jgit.transport.UploadPack.sendPack
(UploadPack.java:471)
at org.spearce.jgit.transport.UploadPack.service
(UploadPack.java:246)
at org.spearce.jgit.transport.UploadPack.upload
(UploadPack.java:227)
at com.google.gerrit.server.ssh.commands.Upload.runImpl
(Upload.java:26)
at
com.google.gerrit.server.ssh.commands.AbstractGitCommand.service
(AbstractGitCommand.java:61)
at
com.google.gerrit.server.ssh.commands.AbstractGitCommand.access$100
(AbstractGitCommand.java:29)
at com.google.gerrit.server.ssh.commands.AbstractGitCommand
$1.run(AbstractGitCommand.java:45)
at com.google.gerrit.server.ssh.BaseCommand$2.run
(BaseCommand.java:253)


The client-side error was different in this case, but I wonder if both
problems could be caused by OOM exceptions:

$ repo sync
Fetching projects: 1% (2/166) ControlSocket /tmp/ssh-nRZtnN/master-
lar...@myserver.com:29418 already exists, disabling multiplexing
remote: Counting objects: 447, done
remote: Compressing objects: 100% (122/122)
fatal: internal server error/122), 50.88 MiB | 2707 KiB/s
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
error: Cannot fetch platform/repository

Any solution to this, other than upping the memory we give to gerrit?

Thanks!
Brad

On Oct 2, 4:33 pm, Shawn Pearce <s...@google.com> wrote:

Shawn Pearce

unread,
Oct 22, 2009, 3:59:45 PM10/22/09
to repo-d...@googlegroups.com

Nope, gerrit needs more heap space, nothing you can do but increase it.  Or reduce concurrent load so less heap is required at once.  If that was only one client active, then reducing load is obviously not an option.

FWIW C git shows the same behavior when malloc fails due to too low of a ulimit on data segment size... and the solution again is to just up the allowed memory usage.

> On Fri, Oct 2, 2009 at 14:29, Brad Larson <bklar...@gmail.com> wrote: > > > Occasionally I have us...

--~--~---------~--~----~------------~-------~--~----~ To unsubscribe, email repo-discuss+unsubscribe...

Reply all
Reply to author
Forward
0 new messages