[yoavm]

I never had the urge to rewrite the history of my code until I started using CI & CD. Since then, it happened to me few times that I wanted to fix something small and ended up trying multiple times, pushing a new "maybe this time?!" commit over and over again. Obviously it's not best practice, but it something you do when there's a rush.

Having 10 tiny commits like that are just failed attempts to fix a bug isn't practical. It makes reading and understanding your repository code _harder_. Git rebase helps me keep my log clean and understandable, thus making it something I can work with in the future.

[recursive]

I'm using CI and CD. If I want to find out if I've fixed a bug, I just run the build locally before pushing.

[rjbwork]

Ideally, sure. But I've had to do this before due to the fact that a configuration value in the PaaS I was using was unmodifiable on remote, but modifiable locally, so I had to do a sort of binary search to narrow it down by observing the behavior of the server via changing my code's value a number of times.

He makes a good point, but ultimately I have to agree with someone's point about "pointlessly gilding lillies".

[swift]

On some of the projects I've worked on, although I can easily run a subset of the tests as a sanity check, the full test suite takes hours to run and has to be run on several different platforms because there is a lot of platform-specific code. There's no way I or anyone else can have confidence in any substantial change until it's run through CI. This is a cycle that may repeat many, many times in some cases before some obscure, platform-specific bug can be tracked down. All of those intermediate attempts would quickly totally drown out the signal in the commit history. This is just one of many reasons why for larger projects, rewriting history is really the only practical option.