As a developer working on solving a bug that occurs in multiple (release) branches I want to clone the MR.
This to ensure we have a trial of solving the bug in all relevant branches.
How to use:
- You have an existing MR (feature1 => master)
- Press the 'clone MR button'
- Select the branches you want to clone it to (release1, release2)
- Two new MR's are created (feature1 => release1 and feature1 => release 2) with a link back to the original MR and original issue
- Merge the different merge requests (can maybe automerge if it is a clean merge)
- The original issue now contains linked to all MR's, showing in which releases it was resolved
Maybe call it
backport, as I hear that being used often. Anyway, a good idea and easy to implement. Thanks!
Interesting. I could see wanting to do clone from an already merged MR as well, not just open MRs.
It wont work as you expected since
feature1is usually based on
masterso creating merge request from
release1will cause bringing all those commits that are in master but not in
So in order to backport something into different branches you also need to create different source branches with cherry-picked commits from original merge request
@markpundsack , I agree, cloning from already merged MR is an absolute must have.
Not sure if it is a backport as this is also typically a forward port (image you found a bug in release 4.0 that you need to patch into 4.1, 4.2, 5.0, etc..). Might just be a terminology thing... @dzaporozhets , yes, the clone operation would need to be some type of pre-branch against the destination target, then a cherry-pick / patch operation onto that holding branch. The MR can then be nice and setup for the user. This would be a very helpful feature for enterprise customers, especially folks with complex configurations or managing multiple simultaneous releases they need to support.
Also, from the original issue, the user should be able to see the list of MRs with the following information:
[MR#] [Title/Description] [Status] [Clone button]
This would show all completed and pending MRs.
Also, being able to clone from subsequent MRs as opposed to the original is very helpful. For example, there is a bug that exists in releases 4.5, 4.6, 5.0 and 5.1. In release 5.0 there was some architectural changes. First, the bug is fixed and merged into 4.5. The MR is then cloned against 4.6 and 5.0. The work to get the fix in for 5.0 is much different then 4.5/4.6 due to the architectural changes. So when it comes time to clone to 5.1 it would be much simpler for the user to clone the MR that fixed 5.0 as opposed to the original.
All of these clones should roll up to the original issue for easy auditing / reporting.