Assume that someone is working on legacy code where the complete code is incorrectly indented and every line validates the code-style guidelines.
The user then continues to make changes on a file (lets say with 3000 lines), and applies as a first commit the code-styles from the team automatically, which will have an effect on almost every line. Then he may follow it up with 8 commits to fix only a couple of lines.
When one is reviewing such a merge request, is it possible to review the code without seeing the code-styles changes? The GitLab compare view may even fail to display, because so many lines have been changed. But as a reviewer, I trust the automatic style changes and just want to see the 8 commits which effected only a couple of lines.
I know this situation could be avoided, by making a merge request with the single commit that fixes the code-styles, and then creating another merge request for the other changes. But what if you end up in a situation where someone did it in a single MR. Any chance I can review it without becoming insane?
It's trivial to turn it into two merge requests, and that is the best option. Simplest is to thank them for their work, explain it is very difficult to review as a single request, and if they would split it up themselves.
Or you can do it yourself. Make a branch off their first commit,
git branch <new branch> <first commit ID>, and submit that as a merge request. Merge it. Then rebase the original merge request on master. They'll still get credit for the work.You could also compare their branch with their second commit. Go to the "compare" tool, set their branch as the source and the commit ID of their second commit as the target.
And you could review it commit by commit in the Commits tab.