I tried mirroring on my ARK kernel project (git@gitlab.com:bcrocker/kernel-ark.git): On Repository Settings, Mirroring repositories: Filled in Git repository URL: git://gitlab.com:cki-project/kernel-ark.git Left Mirror direction = Pull Left Authentication method = Password Left Password field blank (documentation doesn't say to fill it in) Clicked on "Mirror repository" A new line appeared under "Mirrored repositories," along with a "spinning beachball" and a trashcan icon. I let it go for HOURS, and it still didn't complete. The settings page says "The update action will time out after 180 minutes. For big repositories, use a clone/push combination." OK, so what's the problem here? Is it because my fork is so far behind the upstream repo? Or is it because the kernel repo is so huge? Or both? What, exactly, is meant by using a "clone/push combination?" Eventually, got Error: 2: Fetching remote upstream failed: fatal: read error Connection reset by peer. So was this just the timeout? Or is something else wrong? I clicked on what apparently turns out to be the "Update" icon (next to the trashcan, WAS the spinning beachball) and eventually got the same result. Later I clicked on the trashcan icon, and the line under "Mirrored repositories" dutifully disappeared. Great, I thought: now I'm back to the status quo ante, which is what I wanted. Tried mirroring again: On Repository Settings, Mirroring repositories: Filled in Git repository URL: git://gitlab.com:cki-project/kernel-ark.git Left Mirror direction = Pull Left Authentication metho = Password Left Password field blank (documentation doesn't say to fill it in) Clicked on "Mirror repository"... ...and got sent to a page that looked like this: (GitLab logo at the top; text was): 500 (centered) Whoops, something went wrong on our end. Try refreshing the page, or going back and attempting the action again. Please contact your GitLab administrator if this problem persists. </quote> How do I get this stuff to work? Is it time to delete my fork and create a new one? Suggestions: There should not be a hard timeout limit. Once the timeout is reached, GitLab should ask whether the user wants to continue. The "spinning beachball" should be replaced with a continually updating progress display. The "delete" (trashcan) function should work as expected, taking the user back to a state from which it is possible to start the attempt over again.