Which is the entire point of it. Why should I look at ten commits when I can look at one and get the same exact data? Why should I pollute my production history for what a is likely a bunch of debugging commits? The branch is a scratchpad, you should feel empowered within your own branch, rebase allows you to be lazy in the development cycle while presenting a nice clean set of changes at the end of it.

You can split your work in multiple commits and at the same time drop/squash debugging or wip changes. The result allows you to go into much better detail than a PR description.

Yes! When you are deep in the code, your brain operates in a non-linear way. You try a solution, it breaks a test. You patch the test. You realize the variable name is wrong. You fix a typo.

Without Squash, the main branch history becomes a timeline of your mental struggle.

With Squash, the main branch becomes a catalog of features delivered.

No body needs to take a trip on the struggle bus with me...

>Why should I look at ten commits when I can look at one and get the same exact data?

For the same reason you have your production history instead of zip file with code)

>while presenting a nice clean set of changes at the end of it

The set, yes, not a single squashed commit.

>The branch is a scratchpad, you should feel empowered within your own branch, rebase

Yes, amend, fixup, rebase. Make it a nice set of small commits.

Most of those 10 squashed commits likely had commit comments like: "Cleanup based on PR feedback." etc.

That's what --amend and --fixup are for.

Which wreaks havoc with githubs shitty code review tool.

Which is an argument against GitHub, not clean commit history

Yep. Rebase rewrites history and all the PR review comments vanish.

Gitlab seems fine with it