phinullfermata

Maybe under the hood, but it's an option on github if you use that, or you can run `git merge --squash` as well.

Uising squah merges has reduced my need to rebase a lot. I don't really care if I have merge commits on a feature branch for a PR if there's a reasonable history on the main branch when I'm troubleshooting an issue with git blame.

Why squash merges? I have a number of team-mates who make local commits on feature branches that make the history look like a series of less-than-useful commit messages. E.g. wip, wip, wip, wip, make it work, wip, wip. All of the context for the change is actually on the PR, so it's really only helpful to see the PR message and have a link to the PR for the discussion on the change.

Someone who doesn't care about the detail can and will stop reading. It's important to get your main point across early because of this fact. The inclusion of detail is helpful but it needs to be in the right place. I think this is why traditional business writing evolved to have an order like summary, recommendation, then supporting evidence.

If you've written things well you can get the best of both worlds. I noticed this in the author's review example. The first paragraph gets a reasonably high resolution description of the problem, then the detail follows in the next paragraphs.

Modern 3-2-1:

3 backup services 2 formats 1 local copy

I guess that could get expensive depending on the services.

mutt