doc/user/project/merge_requests/merge_request_troubleshooting.md
{{< details >}}
{{< /details >}}
When working with merge requests, you might encounter the following issues.
This can occur if Sidekiq doesn't pick up the changes fast enough.
Sidekiq didn't process the CI state change fast enough. Wait a few seconds and the status should update automatically.
Merge request pipeline statuses can't be retrieved when the following occurs:
To enable the pipeline status to be properly retrieved, close and reopen the merge request again.
{{< details >}}
{{< /details >}}
In addition to the /rebase quick action,
users with access to the Rails console
can rebase a merge request from the Rails console. Replace <username>,
<namespace/project>, and <iid> with appropriate values:
[!warning] Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::RebaseService.new(project: m.target_project, current_user: u).execute(m)
{{< details >}}
{{< /details >}}
If a merge request remains Open after its changes are merged,
users with access to the Rails console
can correct the merge request's status. Replace <username>, <namespace/project>,
and <iid> with appropriate values:
[!warning] Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::PostMergeService.new(project: p, current_user: u).execute(m)
Running this command against a merge request with unmerged changes causes the
merge request to display an incorrect message: merged into <branch-name>.
{{< details >}}
{{< /details >}}
If closing a merge request doesn't work through the UI or API, try closing it in a Rails console session:
[!warning] Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::CloseService.new(project: p, current_user: u).execute(m)
{{< details >}}
{{< /details >}}
If deleting a merge request doesn't work through the UI or API, try deleting it in a Rails console session:
[!warning] Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
Issuable::DestroyService.new(container: m.project, current_user: u).execute(m)
If a merge request times out, you might see messages that indicate a Puma worker timeout problem:
In the GitLab UI:
Something went wrong during merge pre-receive hook.
500 Internal Server Error. Try again.
In the gitlab-rails/api_json.log log file:
Rack::Timeout::RequestTimeoutException
Request ran for longer than 60000ms
This error can happen if your merge request:
Users on GitLab Self-Managed can request an administrator review server logs to determine the cause of the error. GitLab.com users should contact Support for help.
In a group, the sidebar displays the total count of open merge requests. This value is cached if it's greater than 1000. The cached value is rounded to thousands (or millions) and updated every 24 hours.
head ref{{< history >}}
head refs 14 days after a merge request closes or merges enabled on GitLab Self-Managed and GitLab.com in GitLab 16.4.head refs 14 days after a merge request closes or merges generally available in GitLab 16.6. Feature flag merge_request_refs_cleanup removed.{{< /history >}}
A merge request contains all the history from a repository, plus the additional commits added to the branch associated with the merge request. Here's a few ways to check out a merge request locally.
You can check out a merge request locally even if the source project is a fork (even a private fork) of the target project.
This relies on the merge request head ref (refs/merge-requests/:iid/head)
that is available for each merge request. It allows checking out a merge
request by using its ID instead of its branch.
In GitLab 16.6 and later, the merge request head ref is deleted 14 days after
a merge request is closed or merged. The merge request is then no longer available
for local checkout from the merge request head ref anymore. The merge request
can still be re-opened. If the merge request's branch
exists, you can still check out the branch, as it isn't affected.
glabglab mr checkout <merge_request_iid>
More information on the GitLab terminal client.
Add the following alias to your ~/.gitconfig:
[alias]
mr = !sh -c 'git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2' -
Now you can check out a particular merge request from any repository and any
remote. For example, to check out the merge request with ID 5 as shown in GitLab
from the origin remote, do:
git mr origin 5
This fetches the merge request into a local mr-origin-5 branch and check
it out.
.git/config for a given repositoryLocate the section for your GitLab remote in the .git/config file. It looks
like this:
[remote "origin"]
url = https://gitlab.com/gitlab-org/gitlab-foss.git
fetch = +refs/heads/*:refs/remotes/origin/*
You can open the file with:
git config -e
Now add the following line to the previous section:
fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
In the end, it should look like this:
[remote "origin"]
url = https://gitlab.com/gitlab-org/gitlab-foss.git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
Now you can fetch all the merge requests:
git fetch origin
...
From https://gitlab.com/gitlab-org/gitlab-foss.git
* [new ref] refs/merge-requests/1/head -> origin/merge-requests/1
* [new ref] refs/merge-requests/2/head -> origin/merge-requests/2
...
To check out a particular merge request:
git checkout origin/merge-requests/1
These commands can be also be done with the git-mr script.
source branch <branch_name> does not exist. when the branch existsThis error can happen if the GitLab cache does not reflect the actual state of the
Git repository. This can happen if the Git data folder is mounted with noexec flag.
Prerequisites:
To force a cache update:
Open the GitLab Rails console with this command:
sudo gitlab-rails console
In the Rails console, run this script:
# Get the project
project = Project.find_by_full_path('affected/project/path')
# Check if the affected branch exists in cache (it may return `false`)
project.repository.branch_names.include?('affected_branch_name')
# Expire the branches cache
project.repository.expire_branches_cache
# Check again if the affected branch exists in cache (this time it should return `true`)
project.repository.branch_names.include?('affected_branch_name')
Reload the merge request.
If you automate the creation of merge requests, or pushing to them, you might want to build automated approvals for those merge requests. In GitLab Premium and Ultimate, by default, all approvals are removed when commits are added to the source branch. To avoid this problem, add logic to your automation that ensures commits are processed before approving the merge request.
If a merged merge request contains a merged manually system note, the source branch commits
were merged either outside the GitLab UI or as part of a different merge request.
When you use git merge to merge a branch directly into the target branch outside of the UI,
GitLab detects the operation and marks the merge request as merged manually.
This can occur when direct pushes to the target branch are allowed. To prevent this situation, you can protect the target branch and configure it to not allow direct pushes (Allowed to push and merge is set to No one).
For more information, see protect a branch.
The merge request contains commits that were already merged as part of a different merge request. If this occurs on a protected branch, the commits were approved before being merged, in accordance with the protected branch settings.
For more information, see multiple branches containing the same commit.
[!note] In some cases, GitLab may show
merged manuallyinstead ofMerged with !<merge_request_id>. For more information, see issue 456426.