One thing that I've really liked about Gerrit is the git commit --amend && git review -R workflow, where even though I've made multiple changes based on comments, I can look back at a particular commit and identify exactly what was changed and which file were affected in a particular change without having to even get out of the current context (command line, Gitiles, Github). The PR workflow on the other hand allows (and in fact encourages) users to make multiple commits for one PR, where one change can get spread over multiple commits, some of them affecting other files as the code review progresses (and/or the user realizing any mistakes they have made). This can make it sort of difficult to isolate particular changes since I don't think we will have much context as to which PR a particular commit relates to outside the Gitlab instance.
Topic on Talk:GitLab consultation
Please see the "squash merge" comments elsewhere on this page, I think it offers a compelling substitute. At the same time, it makes it easier to follow the evolution of a larger patch by looking at the original feature branch.
Aren't feature branches usually deleted after they are merged?
Feature branches are typically deleted after a merge (there's a checkbox for this on the merge request in GitLab), but their history is still viewable on the merge request itself. See here for an example.
That's only visible in GitLab itself, right? If so, that's a less than ideal solution for the case of doing squash merge on big changes. For example, you cannot git bisect them.
Squash on merge is wonderful. You lose a little detail but you definitely get a similar behavior. Without squash on merge I would have thrown my computer out the window many times looking for a particular feature change.