Merge Request Changes count flips when scrolling

Summary

Zendesk: https://gitlab.zendesk.com/agent/tickets/563654

Customer noticed a small merge request showing 4 changes in the summary, but when scrolling down, it showed 1708+ changes. The additional 1704+ changes were included into the MR after merging from another branch.

The problem is that this change is confusing: is the MR including 4 changes (the original commit), or 1708+ changes (the commit plus all the merged commits from the other branch)?

The number displayed in the top of the MR's "Changes" should remain constant and either show one or the other. Preferably it should count only the number of changes in the commit being viewed, whether scrolled down or not.

Steps to reproduce

  1. Create a new project with "Git Flow"-style long-lived branches for main, qa, and live
  2. Add a feature branch, feat_0 from qa and include a simple change.
  3. Create an MR for feat_0, but do not merge
  4. Observe the Changes shows 1 change: the simple change from (2)
  5. Add a feature branch, feat_2 from main and include multiple additional changes
  6. Create an MR and merge feat_2 into main
  7. "Back-merge" the changes from main into feat_0, push this to GitLab
  8. Observe the Commits for feat_0 lists the changes for feat_2 and the merge commits. This is expected
  9. Click on the first commit for feat_0. The MR moves to the Changes tab and shows [Changes 1] at the top
  10. Scroll down until the MR header is compressed. The display is now [Changes 1+n] where n is the number of changes merged in

Example Project

The Repository Graph from the example project illustrates this more clearly

image

Example MR showing this problem: https://gitlab.com/mlockhart_ultimate_group/tickets/563654_changes_flip/-/merge_requests/1+

What is the current bug behavior?

The "Changes [x]" number will change, when you scroll down the changes for a commit, and then change back when you scroll up. The number "flips" between the count of changes in the commit being viewed, and the total changes for the MR.

What is the expected correct behavior?

The "Changes [x]" should remain constant irrespective of scrolling, and show one count or the other. For the Changes when viewing a commit, it makes sense that it should be the count of changes in that commit only.

Relevant logs and/or screenshots

  • Showing the header and "Changes [1]":

    image

  • Scrolled away the header, and "Changes [7]":

    image

  • Video

    changes_flip1k

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

This bug happens on GitLab.com

Results of GitLab application Check

This bug happens on GitLab.com

Possible fixes

Edited by Mike Lockhart | GitLab