Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • heptapod heptapod
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 190
    • Issues 190
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

April 05-07 - Mercurial Paris Conference 2023 - One day of workshop dedicated to Heptapod and Mercurial usage and workflow. There are still places available for both workshops and talks!

  • heptapodheptapod
  • heptapodheptapod
  • Issues
  • #215
Closed
Open
Issue created Mar 20, 2020 by Raphaël Gomès@raphael.gomesMaintainer

MRs based on another MR don't update their commits once base MR is merged

Summary

If MR2 is based on MR1 and MR1 gets merged, MR2 still shows MR1's commits as being part of the MR.

What is the expected correct behavior?

I expect the newly published commits to disappear from MR2. I would argue that there should be a difference in visibility between commits from MR1 and MR2 from MR2's page, but that may be another issue.

Maybe this is a Gitlab issue and will be fixed by the current Gitlab 12.2 rebase?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking