[DreaminDani]

> what are the downsides of having those commits?

In my experience, having to rebase on top of a branch with a lot of "lint" "quick fix" "let's try this" "oops, how about this" can be draining and sometimes lead to accidental code deletion.

I like squash merges because I know it was the author's intended change that I'm merging or rebasing onto.

[kstenerud]

Yup, agreed.

I've worked in orgs that use long lived branches and short lived branches... And short lived branches are by far less stressful to deal with if you can do it, precisely because of merge conflicts.

Reality is never going to match your desire. Things are going to get messy, and so you end up with squashable commits among your commits that shouldn't be squashed. The branch you're merging should match your intent for atomic changes to the code that can be easily reasoned about when rebasing, merging, and bisecting.

You write to history once, but you read from it many times. Therefore, optimize for reads.

[lucasoshiro]

> In my experience, having to rebase on top of a branch with a lot of "lint" "quick fix" "let's try this" "oops, how about this" can be draining and sometimes lead to accidental code deletion.

" But this is not always possible, so one can use the rewriting history tools that were mentioned."

> I like squash merges because I know it was the author's intended change that I'm merging or rebasing onto.

Can you elaborate, please?