Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Issues
  • #1000

Closed
Open
Created Jun 28, 2012 by Administrator@rootOwner

Timeout issues - Gitlab error page

Created by: danielkummer

We've started using the Gitlab server in production and are experiencing timeout issues with more users using it... The result is always the "Gitolite Error Page". I think a good way to go about it is retrying failed gitolite operations more times before presenting an error screen for the failed operation. If there's some potential for improval of the whole gitolite handling it would also work towards solving the problem...

Question: Why isn't the gitolite-admin repository clone kept and only updated before changing the configuration? It seems to me gitlabhq always clones a fresh copy of the admin repository just to (for example) add a new user or repository.

Assignee
Assign to
Time tracking