When comparing between two versions of a merge request, it shows modifications that were merged from the target branch
Steps to reproduce
Create a branch "A" from master
Create a merge request for "A" and target it to master
Make some commits to "A" with modifications
Make other commits and modifications to the master branch
Merge the master branch with "A" (bring the modifications from master to branch "A")
Compare between the first version and the last version
What is the current bug behavior?
Comparing between versions will show the changes done in the target branch
What is the expected correct behavior?
Code that is already in the target branch should not be shown as a change (since it interferes with reviewing the merge request, these are changes that are not related to the merge request)
@oswaldo I think this is a long-standing gitlab-ce2278648, not a gitlab-ce3630472. As you've identified, the issue is that to compare versions, we use a simple .. diff, which will show all changes between the two SHAs, including those pulled in from a different branch. I'm sure we already have an issue for this, although I can't find it...
@DouweM I tried searching for an existing bug/issue before opening this but couldn't find it either...
The widget you mentioned would certainly help understand whats going on! It took me a while to understand what was going on myself (at first I thought the intern had merged from master while targeting the stable branch). The widget would be a quick-fix or workaround, faster than fixing the actual bug...
But I just want to kindly request that you don't stop there, since this bug interferes with the ability of reviewing the code because it adds a lot of noise (code changes that are unrelated to the merge request), hindering the feature useless in these cases.
But I just want to kindly request that you don't stop there, since this bug interferes with the ability of reviewing the code because it adds a lot of noise (code changes that are unrelated to the merge request), hindering the feature useless in these cases.
This is actually an underlying deficiency in git to some extent. GitLab implements the merge view by defaulting to the equivalent of git diff target-branch...feature-branch. This will show all files and changes that have occurred on feature-branch since it forked from target-branch. If you override the default version selection to select old-version and new-version then you're getting git diff old-version...new-version. If there was a merge of target-branch into the feature-branch between the old-version and new-version commits on feature-branch, then it will show all the modifications that have occurred on target-branch between when the feature-branch prior to old-version forked from target-branch and when target-branch was merged into feature-branch prior to new-version.
The best you can reasonably hope for from GitLab is probably to have an optional toggle that will exclude files that were not changed as part of feature-branch. This would be roughly the equivalent of the command-line command: git diff old-version...new-version -- $(git diff --name-only target-branch...feature-branch). Any files that were changed as part of feature-branch but were also changed on target-branch between old-version and the point where target-branch was merged into feature-branch would still show up as additions, but you'd eliminate showing any files that were changed solely in target-branch that are only showing up because of the merge from target-branch into feature-branch.
Even so, I'd +1 to have such a checkbox...
Hi, it is really difficult to do code review in gitlab with this issue. The other workaround is to push new changes to an existing Merge Request, without syncing with upstream branch, which results in merge conflicts in the upstream branch.
Contributions like this are vital to help make GitLab a better product.
We would be grateful for your help in verifying whether your bug report requires further attention from the team. If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please comment on this issue.
This issue has been inactive for more than 12 months now and based on the policy for inactive bugs, will be closed in 7 days.
Thanks for your contributions to make GitLab better!