I suggest you ...

provide squash option when merging merge requests

Add a checkbox "Squash into one commit" below "Merge" button of a merge request. The default state of that checkbox should be configurable per instance and per project.

The UI would ask for a commit message (defaulting to branch name) and then execute the equivalent of 'git checkout other-branch; git merge --squash this-branch; git commit -m "commit-message", close the merge request and delete the branch (if the other checkbox is ticked).

This is a common workflow in projects and not supporting it causes a lot of confusion and extra work.

248 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Aigars MahinovsAigars Mahinovs shared this idea  ·   ·  Admin →

    11 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Ciro SantilliCiro Santilli commented  · 

        The question in my mind is: who would be the author of the new commit if the merge request has multiple authors. `merge --squash` just creates a new commit under the current author by default. We can of course make Gitlab chose an author smartly, maybe just chose the one who made the most commits, and if draw take the one who made the earliest commit.

      • Ciro SantilliCiro Santilli commented  · 

        @Fabio: I believe they are not the same: rabase changes history, and this does not: it creates a single commit on top of the target that is the squash of all new commits.

      • Sam GleskeSam Gleske commented  · 

        This would be more useful if GitLab tracked in a single merge-request multiple force push revisions. That is to say if the state of the MR has been changed you should be able to see the old state and the current state as well as N number of changed states. I would submit that as another feedback issue but I'm currently out of votes. Having that capability would compliment another feedback of mine nicely: http://feedback.gitlab.com/forums/176466-general/suggestions/6306111-more-robust-code-diff-ing-in-mr

      • Andrew MeyerAndrew Meyer commented  · 

        @Gerard "Once the commit has been pushed, the oppoortunity for squashing has been lost" That's actually not true. After the code review is complete, you can squash + force push.

      • Gerard StannardGerard Stannard commented  · 

        Having to squash locally at the command line means we don't push small commits for immediate code review feedback. Once the commit has been pushed, the oppoortunity for squashing has been lost, so developers tend not to commit until they're ready to squash many small commits.

      • Jody MulkeyJody Mulkey commented  · 

        Currently, merging using the GitLab UI results in all commits within the source branch being inserted into the history of the target branch. For a large feature or fix with lots of commits, this clutters the target branch with potentially extraneous commits. This clutter can make it difficult to cherry-pick features/bug fixes into and out of other branches (for releases, for example), and build clean release notes.

        This can be worked around by doing manual command-line steps to merge the source into the target. It would be extremely convenient, however, to do this from the GitLab UI.

      • Erik DonohooErik Donohoo commented  · 

        I can't stress how important this is. It would be magnificent to have this.

      • Ryan ShelleyRyan Shelley commented  · 

        This would be extremely useful as part of our GitFlow process to be able to create releases of individual features. More importantly, the ability to extract a problematic feature from a release (feature that wasn't completely tested or is buggy). Otherwise it's difficult to revert the individual commits of a feature to remove it from a release.

      Feedback and Knowledge Base