Skip to content
Zide Zide Zide

Merge requests

You can browse and filter merge requests for your GitLab repository from Merge Requests.

The line above the list says how many merge requests there are. With no filter conditions it says N merge requests. With any condition, the default open state included, it says N matches. Each condition shows as a chip above the count. To remove all of them, click Clear filters at the end of the count line. In a narrow panel the button says Clear. Warnings still explain incomplete data.

To open Merge Requests activity, click DevOps > Merge Requests.

Merge requests are listed numerically and display the following information.

  • State badge: The badge that indicates if a merge request is open, closed, merged, or a draft.
  • Merge request number: The number of the merge request, for example !12. As in GitLab, Zide writes merge request numbers with ! and issue numbers with #. The tab title, the Merge Request view, reports, Markdown and HTML exports, and Zide Assist use the same form.
  • Merge request title: The title of the merge request.

The Merge Requests activity first lists enough merge requests to fill the panel, up to 30. Zide then reads the next page in the background, and more pages as you scroll toward the end of the list. Click Load more at the end of the list to read the next page at once. Reports and exports become available once every matching merge request is loaded.

When a project is shown, Zide reads this first page in the background, so Merge Requests shows it at once when you open it. Zide then reads the page again and updates the list only if it changed. Until that read is done, Load more is not available. If the read fails, the list keeps the merge requests it shows.

To open a merge request in a separate tab, right-click the merge request and click Open in New Tab.

Merge Request view

Click a merge request to open the merge request in the Merge Request view. Click Conversation, Pipeline jobs, and Changes to change the displayed information of the Merge Request view. The view names show no counts. A ! next to a name means that Zide could not load that view, or loaded only part of it. When you return to the merge request with Back, the view that you left opens again.

The pipeline badge in the header shows the status of the merge request’s latest pipeline. Click it to open the pipeline in the Pipeline detail tab.

Conversation view

You can view every comment and action of a merge request in the Conversation view. The Conversation view displays the merge request and the following information.

  • State: The status of the merge request, if the merge request is open, closed, or merged.
  • Milestone: The milestones associated with the merge request.
  • Assignees: The users assigned to the merge request.
  • Reviewers: The users assigned to review the merge request.
  • Labels: The labels attached to the merge request.
  • Linked issues: The issues linked to the merge request.

Click Commits under the metadata to see the commits in the merge request. Click a commit to open it. The button is dimmed when there are no commits.

Click the State pill to close or reopen a merge request, convert it to a draft, or mark it ready for review. The menu shows the actions available for its current state. Once merged, the request cannot change state.

To move through a long conversation, use the minimap beside it. Blocks shows one mark for the description, each comment, and each review. Each mark reflects the length of its entry. Marks for approving reviews are green. Marks for reviews that request changes are amber. Point to a mark to preview the author and the start of the text. Click the mark to scroll to that entry. To show or hide the minimap, right-click the conversation or the minimap and choose Blocks or Hidden under Minimap.

Conversations start with Blocks. Your choice applies to every pull request and merge request conversation, and Zide keeps it after a restart. The Changes view has its own minimap, which follows your choice for diffs.

To copy text from the conversation or from a diff in Changes, select it, right-click on it, and click Copy. See Copy selected text.

Activity, such as approvals, title changes, and review requests, shows as a line with an icon for the kind of activity, the user, and the time. Zide shows GitLab’s text for each line.

A push shows as pushed N commits. Zide counts the commits that are new in the merge request version that the push made. Click the line to show these commits and Compare with previous version.

  • Click a commit to open it in the Commit tab.
  • Click Compare with previous version to open the Compare Refs tab with the changes since the previous version. The button is dimmed for the first version, and when the project is not a Git repository. Point to the button to see the reason.

Zide reads the commits and the comparison from the project’s local repository. If the project is not a Git repository, the commits do not open. If a commit is not in the local repository, for example before you fetch a recent push, the Commit tab shows Failed to load commit details. Fetch the branch and try again, or open the merge request on GitLab.

After a push that merges the target branch, Zide can show fewer commits than GitLab’s text. GitLab also counts the commits that the merge brought in from the target branch. If GitLab does not give the commits of a version, the line shows GitLab’s text, such as added 5 commits, and only the button. If Zide cannot read the versions, the push shows GitLab’s text and its list of commits.

To see the merge request on GitLab, click the source badge at the right of the tab header, then click Open on GitLab.

Pipeline jobs view

Open Pipeline jobs to see the jobs of the merge request’s latest pipeline. The header shows the pipeline status, the pipeline number, and the merge request’s latest commit. The jobs are grouped under their stage names. Each job shows its status and duration. allowed to fail appears next to a failed job that is allowed to fail.

  • Click the pipeline number to open the pipeline in the Pipeline detail tab.
  • Click a job to open the Pipeline detail tab with that job open, including its log.
  • Click the commit to open it.

If the merge request has no pipeline, the view says so. If Zide cannot load the jobs, or loads only some of them, a notice tells you and offers Retry. Jobs that loaded earlier stay below the notice. If the jobs belong to a different commit than the merge request shows, a notice offers Refresh.

Zide does not update the jobs while they run. To see their latest status, press F5 (Refresh).

A merge request from a fork can run its pipeline in the fork’s project. Zide lists the jobs, and the Pipeline detail tab shows that pipeline from the fork. See Pipelines from a merge request.

Changes view

Open Changes to view the changed files in a merge request. Use the dropdowns to filter by status or file type, or to show viewed, unviewed, or unavailable files. Type a file name in Filter files to find matching files.

Comments on lines of a file show as threads under those lines. In the file list, a badge next to a file shows its number of unresolved threads.

  • To resolve a thread, click Resolve. The thread collapses and shows that it is resolved.
  • To open a resolved thread again, click Unresolve.

The button is dimmed until GitLab accepts the change. If GitLab rejects it, Zide shows the reason and loads the current state of the threads. Text that you typed in a Reply box and did not send stays.

Merge Request report

To open GitLab merge request reports, choose DevOps > MR Report and select a report from the Report Gallery. While a report is open, choose Change Report to select another report. Use the filter control to change the merge requests summarized by the report. For details, see Merge request report.

Create a new merge request

Use Generate in the Content header to draft the title and description with Zide. Its label stays visible when the fields contain text. Hover or focus the button to highlight both affected fields. Existing drafts open a review with selectable results, and applied results offer Undo. Review the content before creating the merge request.

To create a new merge request, complete the following steps.

  1. Click DevOps > New MR, or click New Merge Request in the Merge Requests activity.
  2. In the New MR tab, choose the Compare branch (the source) and the Base branch (the target). Each field lists the local branches of the repository; type to search the list.
  3. In the Title field, enter the merge request name.
  4. Optional: Add reviewers and assignees to the merge request in the Metadata section. Labels and milestones are not currently supported by Zide’s GitLab create path.
  5. Enter the merge request description in the Description field and click Create Merge Request.

A red asterisk (*) marks a required field. Create Merge Request is unavailable until both branch fields name local branches, the branches are different and have commits to propose, the Title field has text, and no attachment is uploading. Point to Create Merge Request to see the reason. If you leave the Title field empty, a message shows below it.

Zide pushes the compare branch to the remote that Git pushes it to, not to the project that Code Review uses. Zide cannot create a merge request from a fork yet. When the branch is pushed to a fork, the New MR tab says so, and Create Merge Request is unavailable. Click Create on GitLab to open GitLab’s New merge request page from the fork to this project. See Project header layout.

Filter merge requests

By default, the Merge Requests activity displays all open merge requests in a repository. Click the filter selector, the filter name after Filter:, to choose another filter. See Saved filters.

Click Show or hide filters to open the filter panel. It shows the common filters first: Search, State, Author, Reviewer, and Label. Click Advanced Options to show Approved By, Assignee, and Milestone. Each tab remembers whether Advanced Options is open. You can combine filters: a merge request must match all of them. Press Ctrl+F (Cmd+F on macOS) to open the panel with focus on Search.

Each filter takes one value. Click a filter, then click a value. The value replaces the filter’s current value, and the list closes. The current value is highlighted. To remove the filter, click Clear at the bottom of the list, or click the x on its chip. To hide merge requests that have a value, see Exclusions.

My MRs shows the open merge requests that you opened. Review Requests shows the open merge requests where you are a reviewer, also the ones that you already approved. Both use the GitLab account that the project uses, also on a self-managed GitLab server.

To search merge requests, click Search in the filter panel and type the words. Choose where to search, then press Enter or click Apply:

  • In titles and descriptions (the default) shows a Text chip.
  • In titles shows a Title chip.
  • In descriptions shows a Description chip.

GitLab shows the merge requests that contain all the words in the place that you chose. A filter has one search, so a new search replaces the current one. Click the chip to change the words or where to search. For In titles and descriptions, Zide searches for each term as words: it puts quotation marks around a term such as label:bug or OR, so the term does not filter the list. To filter, use the filter buttons. In titles and In descriptions cannot contain quotation marks; Zide removes them.

Approved By

Approved By shows the merge requests that you approved (Me (@me)), that anyone approved (Anyone), that no one approved (No one), or that a project member approved. It does not show whether a merge request has all the approvals that it needs.

Approved By needs GitLab Enterprise Edition, which GitLab.com uses. On a GitLab Community Edition server, Approved By is dimmed, and its tooltip says why.

The lists of users in Author, Reviewer, Assignee, and Approved By show up to 100 project members. Type in the search field of a list to find a user.

Exclusions

To hide merge requests that have a value, or to show those with several labels, click Advanced Options and check Show Any / All / None. Then the Assignee, Author, Label, Milestone, and Reviewer filters show their values in two columns. Choose a value in None of to hide the merge requests that have it. Choose a value under All of or Include to show only the merge requests that have it:

  • All of (labels): checkboxes. Shows merge requests that have all the checked labels. GitLab cannot show merge requests that have any one of several labels.
  • Include (other filters): round buttons, for one value. Choosing another value replaces it.

GitLab hides merge requests by one author, one reviewer, and one milestone at a time, so None of also has round buttons for these filters. Labels and assignees have checkboxes in None of, for any number of values. A column with round buttons has its own Clear under its heading, which clears only that column. A value can be in one column only.

To show only the merge requests with one value, click the name of that value. This clears the other values of that filter and closes the list. Click Done or press Escape to close the list. Clear at the bottom removes all values of the filter. Each filter shows as one chip, for example Label: not blocked.

Point at Show Any / All / None to see which filters it changes: their borders change color. Each tab remembers this setting. While a filter has more than one label or a value under None of, the checkbox stays checked and is unavailable, and the text below it names those filters. This also happens when you choose a saved filter with such values.

To find merge requests where a field is empty, open Assignee, Label, or Milestone and choose No assignee, No labels, or No milestone. To find merge requests where it is set, choose Has assignee, Has labels, or Has milestone. The choice replaces the other values of that filter. With Show Any / All / None checked, select the checkbox or round button beside Has … to keep the values under None of: Has labels with documentation under None of shows labeled merge requests without that label. Clicking the name Has … makes it the filter’s only condition. Click Clear or the chip’s x to remove the condition.

If you open a filter before its list has loaded, a line such as Loading labels… (or users, milestones) shows in it until the list arrives. If you choose another remote for Code Review in DevOps > Configure…, the list and its filter choices reload for that repository. Your filters stay selected.

Saved filters

Click the filter selector to see these groups:

  • Built-in Filters: filters that Zide provides: All MRs, Open MRs, My MRs, and Review Requests.
  • Saved Filters: filters that you saved for this project. Save Current Filter As… at the top of this group saves the current filters with a name that you enter, and selects the new saved filter.
  • Recent: filters that you used recently but did not save.

A check mark shows the selected built-in or saved filter. Ctrl+click (Cmd+click on macOS) a filter to open it in a new tab.

When you change a saved filter, the list updates at once, but the saved filter does not change. The selector shows the filter name followed by (modified), or an asterisk in a narrow panel. The filter list then starts with two items:

  • Save Changes saves your changes to the saved filter.
  • Discard Changes restores the saved filter and refreshes the list.

If you choose another filter without saving, Zide keeps your changes in Recent under the filter name followed by (modified). Recent keeps one such entry for each saved filter: newer unsaved changes replace the older ones. To keep a variant, save it with Save Current Filter As…. Choose the entry to continue: the saved filter opens with your changes, ready to save or discard. If the saved filter was deleted, the entry opens as an unsaved filter.

A filter that is not saved, such as a built-in filter that you changed, is named after its filters. Recent uses the same name.

To rename or delete a saved filter, click the More actions button (⋮) next to it in the list, then click Rename… or Delete…. These actions apply to that filter, also when you use another filter. Deleting a saved filter does not delete or change any merge requests. If you delete the filter that you use, the list changes to Open MRs.

In the list, the arrow keys move between filters, and Shift+F10 opens the More actions menu of a saved filter.

Saved filters belong to the project. The activity and the MR Report tab use the same saved filters. Issue filters are saved separately.

Unsupported filters

If a filter has a condition that Zide does not support for GitLab merge requests, Zide does not load merge requests. A notice names the conditions, and their chips show Unsupported. Click Edit filters to change the filter, or click Show open MRs. Zide does not support these conditions for GitLab merge requests:

  • More than one search in a filter. A filter saved in an earlier version of Zide can have a title search and a full-text search.
  • A search saved in an earlier version of Zide that has parentheses or terms such as author:alice In titles and descriptions, or quotation marks In titles or In descriptions.
  • Approved By on a GitLab Community Edition server.
  • GitHub’s review status and CI status.
  • GitHub’s Project, No project, and Has project.
  • Included values together with No … or Has … for the same field, for example Has labels with Label: bug, or No labels together with Has labels. A filter saved for GitHub can hold such a combination. Exclusions under None of can go with any of them.

Assist with This

Right-click a merge request, or the tab of a Merge Request view, and point to Assist with This. You can also right-click the content header or an ordinary background area in the detail tab.

Under Zide Assist, click Add to Conversation to attach the merge request to a Zide Assist tab. You can also drag the merge request into a Zide Assist tab. For more information, see Attach items to a message.

Under Ask Zide, click Open Ask Zide. Zide opens the merge request in the Merge Request view with an Ask Zide panel beside it. In the panel, click Summarize Changes or Review Changes. Ask Zide does not post a review, approve, or merge. See Ask Zide beside a tab.

Check and pipeline status indicators use blue for running or queued work, amber when user action is needed, red for failures, and green for success. Cancelled, skipped, and unknown results are neutral.