### Summary While trying to merge a few commits (that I had just nicely split up), I hit the big blue "Merge when pipeline succeeds" button. However, the "Squash commits" checkbutton must have been set, something that I simply did not see. Which really isn't surprising as I never ever use that feature (I didn't even realise it *exists*). I feel the UI should be improved to make this more obvious. e.g.: * Make it the mergers choice what to do, not the submitters * Let the button explicitly state the action "Squash and merge […]" * Add a setting to disallow users to even set it * Only open the commit message expander, then have a second button below (i.e. making it a two step action and also getting a confirmation for the commit message). Not sure … I am obviously a unhappy as it caught me completely by surprise. Below is my original report. ----- A merge with three commits was squashed during while merging. The commit message of the middle commit was kept, but the repository is set to do fast-forward merges only. ### Steps to reproduce I did the following, have not confirmed if it is reproducible: * Checked out fork'ed repository (not mine) * Rewrote the history to split a commit (and change a comment) * Force pushed into the user repository * Rebased from the MR * Merged This is the MR in question, you'll see the three commits: * https://gitlab.freedesktop.org/libfprint/libfprint/-/merge_requests/144 * `5f71cc83 - vfs0050: Attach SSM to transfer to fix an assertion` * `f0c34e1a - vfs0050: Stop capture after a timeout happens` * `679a49d8 - vfs0050: Fix byte offset calculation into struct` The pipeline ran through for `679a49d8`, and it was then merged. But the merged commit is `1b74813a` which has the commit message from `f0c34e1a` and actually is a squashed version of my commits (not the submitters, then one of the comments would be different). So the code is correct, but the commit history got mangled. The project *is* set to only allow fast-forward merges.