GitLab Merge Request Delays and Commit Failures with High Volume File Changes
Summary When performing commit operations through REST API endpoints on GitLab SaaS repositories, merge requests containing a large number of files (around 250 or more) experience substantial delays in reaching the MERGEABLE status, even after waiting for 60 minutes. Although the initial file upload completes quickly, this issue negatively impacts functionality and user experience. Similar operations on other Git providers—such as GitHub, Azure DevOps, and Bitbucket—do not exhibit this behavior. The GitLab API fails when attempting to commit more than 100 files in a single commit request. To merge a large number of files into a GitLab repository, we follow these steps: Create a temporary branch. Commit files to the temporary branch in batches. Create a merge request to merge the temporary branch into the target branch. Wait for the merge request to reach the 'mergeable' state before accepting it. However, we are experiencing unusually long delays waiting for the merge request to become mergeable.
Impact: • The delays impact workflows that depend on timely merge operations, adversely affecting our customers in production. • Since we support version control across multiple Git providers, customers view this as a performance limitation of GitLab compared to other platforms.
Questions / Clarifications Requested:
- Is there a documented limitation on the number of files that can be committed in without triggering merge request delays or failures?
- Is there a recommended best practice for committing multiple files(100+) without this delay?
- Can you share if there are optimizations planned or available to mitigate this delay for cloud-hosted GitLab repositories?
- Is there any documentation available that explains the delays experienced during merge requests?