2019-09-04 21:01:54 +05:30
|
|
|
---
|
|
|
|
type: reference, concepts
|
|
|
|
---
|
2016-09-29 09:46:39 +05:30
|
|
|
|
2019-09-04 21:01:54 +05:30
|
|
|
# Merge requests versions
|
2016-09-29 09:46:39 +05:30
|
|
|
|
|
|
|
Every time you push to a branch that is tied to a merge request, a new version
|
|
|
|
of merge request diff is created. When you visit a merge request that contains
|
|
|
|
more than one pushes, you can select and compare the versions of those merge
|
|
|
|
request diffs.
|
|
|
|
|
2016-11-03 12:29:30 +05:30
|
|
|
![Merge request versions](img/versions.png)
|
|
|
|
|
2019-09-04 21:01:54 +05:30
|
|
|
## Selecting a version
|
2016-09-29 09:46:39 +05:30
|
|
|
|
|
|
|
By default, the latest version of changes is shown. However, you
|
|
|
|
can select an older one from version dropdown.
|
|
|
|
|
2016-11-03 12:29:30 +05:30
|
|
|
![Merge request versions dropdown](img/versions_dropdown.png)
|
|
|
|
|
2019-09-04 21:01:54 +05:30
|
|
|
Merge request versions are based on push not on commit. So, if you pushed 5
|
|
|
|
commits in a single push, it will be a single option in the dropdown. If you
|
|
|
|
pushed 5 times, that will count for 5 options.
|
2016-09-29 09:46:39 +05:30
|
|
|
|
2016-11-03 12:29:30 +05:30
|
|
|
You can also compare the merge request version with an older one to see what has
|
2016-09-29 09:46:39 +05:30
|
|
|
changed since then.
|
|
|
|
|
2016-11-03 12:29:30 +05:30
|
|
|
![Merge request versions compare](img/versions_compare.png)
|
|
|
|
|
2019-09-04 21:01:54 +05:30
|
|
|
Comments are disabled while viewing outdated merge versions or comparing to
|
|
|
|
versions other than base.
|
2016-11-03 12:29:30 +05:30
|
|
|
|
|
|
|
Every time you push new changes to the branch, a link to compare the last
|
|
|
|
changes appears as a system note.
|
2016-09-29 09:46:39 +05:30
|
|
|
|
2016-11-03 12:29:30 +05:30
|
|
|
![Merge request versions system note](img/versions_system_note.png)
|
2016-09-29 09:46:39 +05:30
|
|
|
|
2019-12-26 22:10:19 +05:30
|
|
|
## Find the merge request that introduced a change
|
|
|
|
|
2020-06-23 00:09:42 +05:30
|
|
|
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/2383) in GitLab 10.5.
|
2019-12-26 22:10:19 +05:30
|
|
|
|
|
|
|
When viewing the commit details page, GitLab will link to the merge request (or
|
|
|
|
merge requests, if it's in more than one) containing that commit.
|
|
|
|
|
|
|
|
This only applies to commits that are in the most recent version of a merge
|
|
|
|
request - if a commit was in a merge request, then rebased out of that merge
|
|
|
|
request, they will not be linked.
|
|
|
|
|
2020-04-22 19:07:51 +05:30
|
|
|
## `HEAD` comparison mode for Merge Requests
|
|
|
|
|
2020-06-23 00:09:42 +05:30
|
|
|
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27008) in GitLab 12.10.
|
2020-04-22 19:07:51 +05:30
|
|
|
|
|
|
|
Merge Requests, particularly the **Changes** tab, is where source code
|
|
|
|
is reviewed and discussed. In circumstances where the target branch was
|
|
|
|
merged into the source branch of the merge request, the changes in the
|
|
|
|
source and target branch can be shown mixed together making it hard to
|
|
|
|
understand which changes are being added and which already exist in the
|
|
|
|
target branch.
|
|
|
|
|
2020-05-24 23:13:21 +05:30
|
|
|
In GitLab 12.10, we added a comparison mode, which
|
2020-04-22 19:07:51 +05:30
|
|
|
shows a diff calculated by simulating how it would look like once merged - a more accurate
|
|
|
|
representation of the changes rather than using the base of the two
|
|
|
|
branches. The new mode is available from the comparison target drop down
|
|
|
|
by selecting **master (HEAD)**. In the future it will
|
2020-06-23 00:09:42 +05:30
|
|
|
[replace](https://gitlab.com/gitlab-org/gitlab/-/issues/198458) the
|
2020-04-22 19:07:51 +05:30
|
|
|
current default comparison.
|
|
|
|
|
|
|
|
![Merge request versions compare HEAD](img/versions_compare_head_v12_10.png)
|
|
|
|
|
2019-09-04 21:01:54 +05:30
|
|
|
<!-- ## Troubleshooting
|
|
|
|
|
|
|
|
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
|
|
|
one might have when setting this up, or when something is changed, or on upgrading, it's
|
|
|
|
important to describe those, too. Think of things that may go wrong and include them here.
|
|
|
|
This is important to minimize requests for support, and to avoid doc comments with
|
|
|
|
questions that you know someone might ask.
|
|
|
|
|
|
|
|
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
|
|
|
|
If you have none to add when creating a doc, leave this section in place
|
|
|
|
but commented out to help encourage others to add to it in the future. -->
|