Skip to content

Reorganize merge strategy options

Problem(s) to solve

In a popular issue Squash merge MRs without merge commit, users expressed the desire to be able to merge without the need to create a merge commit. As part of the discussion, it was pointed out that this is essentially achievable with the current settings by using a combination of Fast-Forward Merge (no merge commit) and Require Squashing (forced squash). However, users expressed the following problems with that solution:

  • Some organizations do not want to require fast forward merge because they view it as costly
  • Current settings affect all MRs in the project and users expressed there are times they want merge commits (feature branches) and times they do not (small bug fixes.)

There is also the added concern that the settings are already complicated and adding to them will only make this more confusing.

Proposed solution

This issue is intended to address these concerns by proposing a combination of enhancements

  • Introduce git merge --squash for scenarios not addressed by our current settings (without Fast forward)
  • Reorganized the settings to decouple Fast-forward merge and merge commit
  • Introduce an optional merge commit setting.

By separating out the options of fast forward and merge commit we can improve the clarity of the options and no longer force the user to discern the differences by the help text. This also reduces the number of permutations required (2x2=4 or 2x4=8 if we include allow and encourage) while increasing the granularity of the options.

Optional merge commits could be separated out and iterated on. Designs for the optional in the merge request widget are TBD.

The design includes 👇

  • Removal of Merge method section
  • New setting under merge options to Enforce semi-linear history
  • New section for merge commits
    • Default option should be Require
  • Update squash commits section
    • Update description
    • Replace radio option with dropdowns
    • Update option descriptions

image

Additional designs:

Scenario Current setting New setting
No fast forward, merge commit Merge commit Fast-forward merge - off, Merge commit - Require
No fast forward, no merge commit Not possible Fast-forward merge - off, Merge commit - Do not allow
Fast forward, merge commit Merge commit with semi-linear history Fast-forward merge - on, Merge commit - Require
Fast forward, no merge commit Fast-forward merge Fast-forward merge - on, Merge commit - Do not allow
Fast forward, optional merge commit Not possible Fast-forward merge - on, Merge commit - Optional
No Fast forward, optional merge commit Not possible Fast-forward merge - off, Merge commit - Optional

git merge --squash would be required for:

  • No semi-linear history, no merge commit and squash on
  • No semi-linear history, optional merge commit and squash on

In addition to UI updates, the following would also be needed:

  • Updates to the API to allow settings to be configured
  • Updates to the API when consuming the settings (in merge requests)
  • Updates to quick commands (slash commands) within merge requests
  • Migration strategy to move users to the new settings
Edited by Mike Nichols