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.
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.
@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.
Fabio Sobral commented
As noted by Maxime, this is similar to http://feedback.gitlab.com/forums/176466-general/suggestions/4289653-rebase-merge-requests-in-the-web-ui.
Not exactly the same thing, but kind of different ways to implement the same workflow.
Maybe consider merging both suggestions? IDK how this works.
Sam 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 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 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 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 Donohoo commented
I can't stress how important this is. It would be magnificent to have this.
Ryan 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.
Maxime Brugidou commented