@gthb This is a false binary. Cleaning up history is important, and comes in multiple flavors/methods.

One of which could be squash the branch, *then* merge (as opposed to the current effective "squash rebase"). Lots of cool options are available.

@gthb
On the other hand, squash merge strategies require the whole team to strictly abstain from large parts of git's basic feature set (and usage idioms) – lest you end up with repeated problems that are hard to decipher and to untagle.

Even veteran git users often have a hard time reasoning about how and why things went wrong and frequently end up force-resolving conflicts incorrectly and thereby losing valuable changes (and then the evidence of that gets wiped after the merge).

@gthb Yes.
Squash merges are good for exactly two things:

1. Writing abbreviated history
2. Preventing (sensitive?) metadata leaking.

There are other and better ways to be a neat freak about your git history, and if you want to want to prevent metadata escaping, you should be doing your squashed commits off in a separate repo anyway.

Raw version of the side-scroll prevention script:

```js
if (
navigator.userAgent.indexOf('Chrome') < 0 &&
navigator.userAgent.indexOf('Safari') > 0
) {
document.addEventListener('scroll', function () {
if (document.documentElement.scrollLeft > 0) { document.documentElement.scrollLeft = 0;
}
});
}
```