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.
Continued here: https://gitlab.com/gitlab-org/gitlab-ce/issues/4106
Santeri Vesalainen commented
Hopefully this gets to Community Edition, at least eventually.
Github has just announced similar feature https://github.com/blog/2141-squash-your-commits .
Interesting comments, had to vote/subscribe.
Bruno Lorenço Lopes commented
It would be very nice to have this feature in the community edition!
Ionut DINU commented
this would be a grate feature
Dan Cech commented
+1 on this, it would be great to avoid having a multitude development commits cluttering history in master while still being able to use the web UI to accept merge requests.
In that instance I think it is sensible to attribute the commit by default to the user who opened the merge request, but allow the person doing the merge to select a different user to attribute it to if desired.
The merge --squash option is used as the workflow in several companies I have worked for. This option would be perfect for an enterprise use of git where committing to the master branch should be a single commit per feature or issue. The developer branch will contain the history and incremental commits but once the code review is completed / merge request is finished all other developers care about is the final changes (not intermediate steps)
Tomáš Procházka commented
I vote for this feature. On open source project is great if is possible to trace source of commits, especially if multiple peoples work on it. But in company is completely different situation. Author of the pull request is always one user, if reviewer want some changes it produce more useless commits in the origin branch. And result should be only one commit with desired feature.
@GitLab: maybe this is not what you meant, but just to clarify: `git merge --squash` does not force push and does not touch the source branch: it only creates a new commit.
AdminGitLab team (Admin, Gitlab) commented
In my opinion squashing also changes history, the sha1's and the ordering are now gone from the repo and put into some text. Anything that involves force pushes involves changing history, although I agree that squashing has less of an impact. ^Sytse
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.