Why interested: We have a need setting a default merge method for different branches as per our SCM Strategy
Problem you are trying to solve: So that each branch can choose the default merge type (e.g. prod-support-develop can use merge commit, whereas master can use fast-forward
Current solution for this problem: None
Impact of not having this: We are forced to pick same merge method for all branches
PM to mention: @tlinz for visibility and prioritization
~"Gitlab Ultimate" customer would also like this feature. Would like to use a normal merge strategy on one specific branch while keeping the rest as fast forward with rebasing.
~Gitlab Ultimate customer would also like this feature. Would like to use a normal merge strategy on one specific branch while keeping the rest as fast forward with rebasing.
The company I am working at is using GitLab, and we were planning to optimize our git strategy by using plain revision history inside dev branch (rebase + fast forward merge of task-branches) and filling our main/release branch with merge commits only. These commits contain additional information about branches pushed to dev (task id, short info about it) and are very useful at the moment of release notes creation.
So I started to search over trying to find out how to apply different merge methods to dev- and main-branches and I found this topic which makes me a sad panda.
Is there any kind of a plan to implement the feature described by @apham4?
I don't see "Merge Requests" explicitly mentioned anywhere in this issue, but this is a request concerning the Merge Requests "Merge method" setting, right?
FWIW, @phikai, @adam.jensen.gitlab, this looks like something we might also ideally want to have work differently for protected branches vs other branches - or even arbitrary groups of branches by branch name pattern.
But I could see that it might make sense to define different merge methods for different branches. I will add it to Framework for source code rules (&6351). Please, note, unfortunately we do not have capacity to consider this in this year.
I think it is a bit outside of the scope of Reorganize merge strategy options (&7705). I don't want to add it there as I want to keep that epic small otherwise it will be harder to pick that up.
A Premium (SaaS) customer is interested in this feature (Internal link). The customer indicated that this is something they could do in Bitbucket, but not in GitLab.
As an example, imagine you have two branches master and staging, a dev creates a new branch dev-name/new-feature and makes changes, pushes and makes a merge request to staging.
After you've checked out that everything is good in staging, you make a merge request to master and merge up.
At this point, staging is now 1 commit behind master due to the merge commit. Merging that merge commit back to staging is silly, when those two branches are already identical.
I want staging to always exist and be merged to first and I want to see merge commits.
The only workaround I can think of is to have a pipeline rebase/ff staging in a pipeline when master gets merged, but I still don't want to see Merged master into staging commits :/
We solve this exact scenario creating a MR in Gitlab and going to the CLI to do a git merge --ff origin/staging && git push -- which automatically closes the MR over here on Gitlab.
All we'd need was an option to do this directly into the MR page. As far as we know, either we enable fast-forward in every single MR into project settings or we don't enable them at all, hence the manual approach.
Not being privy to design choices, we really suspect this use case would be a single dropdown/select somwhere in the current frontend interface, making it odd to only have the global configuration option.
Why interested: "For develop and master branch we would like to follow semi linear history model as the same is important from multiple audit, compliance and process perspectives. Same is not the restriction for the other branches. We do have a branch named stage which is another important branch. We have a check during develop merge pipeline that feature branch should be merged in stage branch before it can be merged to develop to ensure that stage environment always have the feature branch code before going to production.
Merge check works based on a latest commit id of the feature branch being present in stage branch. Due to semi linear history configuration being applicable to all branches, if we perform rebase merge of feature branch onto stage branch the commit ids will change and that will result in stage merge check to fail.
To make this work we need to follow a very tedious process of cutting a temp branch from stage, merge feature branch in temp branch and then raise MR of this temp branch on stage branch. This process takes a very long time for each stage merge and consumes considerable amount of effective developer time due to this limitation which can be otherwise utilized for productive work."
@derekferguson / @mcbabin / @dpoosarla is this issue a fit for cocreation if a customer would like to help out building it in the product? See gitlab-com/Product#13611 for guidance what makes up a good issue to work on. At the very least, the PM should be supportive of the direction.
@nick_vh I think ultimately this is something that we want to support. I think the first piece of the puzzle is to get [MVC] Branch Rules Editing (&8075 - closed) completed and then turned on. Once that happens, this is certainly something that could be in scope.
The challenge is likely figuring out what the effort is here since it touches quite a few places in the app and then how that fits into the current efforts.
@mle@alyssatrinh Is this specific feature something that's been thought about in branch rules at all?
@nick_vh Echoing what @phikai said, we would like to go in this direction. I'll need to dig a bit deeper to evaluate whether this would make sense for cocreation, but just in terms of product direction, it matches with what we'd like to do. We simply haven't had the capacity or a few foundational pieces in place yet (like the consolidated branch rules) to make this a priority.
@phikai sorry for the delay. I touched base with @mle about this and we don't have specific designs for introducing merge methods into branch rules, but some tangential design thinking has been done: