Not sure if this is a bug or not, but when we open a **Merge Request** with the "squash" option selected, it should not create a merge commit. What it's happening right now is that the log history ends up with two commits: one with the message from the title of the Merge Request, and the other one specified at the time we hit the Merge button. The (interim) merge commit isn't supposed to be there, otherwise that defeats the purpose (somehow) of the actual squash operation. Basically, I'm expecting to see something like this: ```shell $ git status On branch my-super-awesome-branch ... $ git log commit c4f626ce501082b95237534918d8d578d818da94 more stuff >:( commit 646ec761b5efdb02de6587b14c7e52af50da52be all done (or i guess so) commit 3d0d5dca0b96cded2e960c662f6e08287d2eb7a2 mostly done ... $ git checkout master # ...provided there are no conflicts and things like that $ git merge --squash my-super-awesome-branch $ git commit -m "feature - my super awesome feature" $ git push ``` That will squash merge, as expected, all 3 commits on `my-super-awesome-branch` branch into `master`, creating one and only one commit in the log history. The reason I can't do this from the command-line in the daily basis is because there is no way to tell GitLab's Web interface to close that branch; and if close manually, it will not display correctly that the work is merged/done. This works correctly in Bitbucket and GitHub, as I'm describing it here. Another way would be to have the options to do: `git merge --no-ff`, `git merge --squash`, and `git merge --ff-only`. But the `squash` option is a little bit misleading. --- Another thing I've noticed is that merge commit are not signed – when done from the Web interface.