If the commits are organised and contain useful messages, does the author need to actively state they prefer their commits aren't squashed? It seems implied by the fact that they kept their commits in order. I think people who prefer that will mostly be our maintainers - who are a minority of contributors but account for a majority of PRs.

I'm always curious about this argument. Does anyone really care if the commits are "organized"? What do people do with that organization?

I care when trying to understand why code is written the way it is or since when. Using git blame gives you the commit that a line was changed. It's very helpful then if all related change is in the same commit and all unrelated change is not.

Answering @rcomer's question: Generally, if multiple commits look reasonable (*), we can keep them, no matter if the author stated that explicitly. This may very well happen for experienced non-core devs. They know how to structure compex topics over multiple commits, but may not be aware of our policies.

(*) Reasonable is to a certain extend in the eye of the beholder. One can easily identify the extremes. OTOH, I would not squash commits from other people if they are very clear. I would squash the "small" PRs with many trival commits. If I the PR is too large / touching multiple topics, and I have the feeling it should be split up, I'd ask the author to reorganize - this is likely even necessary for simpler review.

Sure it's good to have reasonable commit histories. I'm just curious why folks would bother being overly meticulous with this. If a change is made in boo.py I'm not too likely to be confused by the blame if a change is also made in doc_boo.rst

But I'm fine if the merger wants to make a judgement call. I guess if in doubt ask. I think 99% of PRs a squash is fine and saves a step as noted in the original justification

Some people just prefer that their own PRs are not squash-merged. I personally do quite like the fact that I can do

git branch --merged upstream/main

and it will tell me which of my branches can be safely deleted. That won't work any more if the branches are squash-merged. That said, this is just a preference, not a hill I'm going to die on.

That won't work any more if the branches are squash-merged.

Eek, that's the only way things get cleaned for me.

I think, like most maintainers, I just do my own rebase squash/plan to get to it after the final round of reviews. Or usually I've done something like tweak css/.toml/conf.py b/c of the PR but unrelated enough that I'll keep it in a separate commit for history/bisecting.

The reason for changing to squash-merge was so that we don't require more inexperienced authors to squash themselves. We could have a case-dependent policy: Stick with simple merge, but squash-merge if the PR commit(s) are not well organized. I think one can usually tell the difference (or ask if not). The downside is that we put the burden on reviewers and they have to select the strategy case-by-case - GitHub UI keeps the last used strategy as default and you'd have to go through the dropdown.

If the commits are organised and contain useful messages, does the author need to actively state they prefer their commits aren't squashed?

I think yes. I don't think it should be on the person merging to consider "oh this person wants X, this person wants Y".

The downside is that we put the burden on reviewers and they have to select the strategy case-by-case

I think that the bottom line of my thinking is that if someone chooses one method or the other, the author should not be upset about it. If someone wanted their commits kept, but they get squashed then 🤷 Make a small PR for each individual change instead with a single commit each which will guarantee those commits get kept separately.

Regarding removing local merged branches:

Rather than checking if a branch was merged, I check if a branch exists on my remote. So after someone merges, I click the "delete branch" button, which then deletes it from my origin. I then have an alias setup locally that I run every so often to prune these branches that don't exist on my origin.
https://stackoverflow.com/questions/13064613/how-to-prune-local-tracking-branches-that-do-not-exist-on-remote-anymore I think this works as expected with squash merges as well because it is comparing branch names, but even if not, I'm sure there are ways I can adapt my local workflow for this.

Keeping your local repo clean is an interesting use case of keeping commits the same. However after a merge I typically delete the branch on GitHub and then it's not on my "origin" remote. I treat my local repo as ephemeral.