error: RPC failed; curl 18 transfer closed with outstanding read data remaining

Ulrich Spörlein uqs at
Thu Oct 29 13:08:53 UTC 2020

On Wed, Oct 28, 2020 at 9:30 PM Dimitry Andric <dim at> wrote:
> On 28 Oct 2020, at 20:54, Ulrich Spörlein <uqs at> wrote:
> >
> > On Tue, 2020-10-27 at 15:13:09 +0100, Dimitry Andric wrote:
> >> I consistently get this error when doing a "git fetch", on a already
> >> populated clone. This is with git 2.28.0, on a FreeBSD 13-CURRENT
> >> client. On the same system, git fetching over https from e.g. GitHub all
> >> work fine, even for the FreeBSD repository. Therefore, I am inclined to
> >> think that some cgit-beta server timeout setting is to blame.
> >
> > Hi Dim
> >
> > just to make sure, as you explicitly write "on an already populated
> > clone", does this also happen with a fresh clone?
> >
> > I think the aggressive repacking between runs is to blame here, as that
> > takes away the potential to send a small diff update. I've now reverted
> > the aggressive GC and have changed the conversion to run 3x per day per
> > repo. (We no longer need the aggressive repack, it was put in place to
> > fix something else :)
> >
> > IOW, please try a fresh clone, and if the future `fetches` to this clone
> > continue timing out over the next few days, we can have another look.
> Yes, this was precisely the advice I got the last time. :)
> I had my fresh clone then, which is now a little bit less fresh, and I
> want to update it, that's really all. Am I really expected to clone the
> whole thing every time...?
> That said, I'm unsure if you use bitmaps on the server side, which
> should speed up operations like this. Are these enabled?

No idea if these were enabled or not. But as I wrote, the aggressive repacking
has only been turned off last night. So, does the problem currently

It would be strange if you're the only one running into this ...


More information about the freebsd-git mailing list