Why do we always squash merge?

[rcomer]

For some time now, the Iris repo has been locked down so that in general PRs can only be squash-merged. I didn't question that for a long time but it seems odd that we have to actively unlock that setting so that merge-back PRs can work sensibly (e.g. #5454). There is also a (slight) disadvantage to contributors in that the squash-merge breaks git's knowledge of whether a branch is merged into main. If I go to my local clone and do

git fetch upstream
git branch --merged upstream/main

For Iris this will only show my default branch, whereas for projects that merge my commits I get a list of branches that can safely be deleted.

So what's the advantage of locking it down like this?

[trexfeathers]

I can currently check out any commit on main knowing that I get a working version of Iris. I can also very easily follow the history of approved changes by running through main's commit history. This has proven useful for:

• Debugging changed behaviour
• Benchmarking
• Understanding decisions

Obviously no-one would deliberately merge-commit a branch containing 30 commits called WIP testing. or similar, but even if that happened once it would cause quite a few headaches.

I agree with the downsides you have laid out, but I feel like the alternative would have more potential downsides.

[pp-mo]

Regarding especially the "Understanding decisions"
Squash-merges guarantee a linear change history, which is simpler, more concise, and far more comprehensible.
I think that's very useful in itself, especially if you need to track down the source of a problem, or the context of when something changed.

A key drawback is that the original development history (commits) is then only available on GitHub.
So for that, it's really important that the squashed commits reference the original PR number. But I think in practice if you need to review past development, the actual commits are usually not that important, whereas the development discussion is highly significant -- which obviously is only on the platform, not in the repo itself.
We recently migrated some internal repos from BitBucket to MetOffice-github, and we just had to accept that we lost this kind of history.

[lbdreyer]

A key drawback is that the original development history (commits) is then only available on GitHub.

From my perspective, this is the greatest disadvantage of the squash-merging. It does occasionally come up that I want the main branch's history to have the change in multiple commits, rather than all lumped together, as the change is clearer if you have the history of it. Squash-merge removes this option, or at least discourages it as I suppose you could split the change into multiple PRs but that is a little more difficult to manage.

[trexfeathers]

I could probably be persuaded that we should have merge-commits enabled, so long as the default option shown was always a squash-merge.

[trexfeathers]

❗ Important note on benchmarking

If we do decide to move away from squash commits, several changes in design philosophy would be needed to bm_runner.py before benchmarking would work properly.

[bjlittle]

@lbdreyer We had a lovely discussion in the @SciTools/peloton and we were tending to the conclusion of keeping the status quo - did you want to argue your case further before we make a final decision?

[lbdreyer]

I really don't feel that strong about this. It's just a small restriction. But I would be interested to understand if more pro status-quo reasons were discussed outside of what @trexfeathers listed above

[trexfeathers]

We discussed how the easy information provided by the squash strategy would still be available to someone with enough Git skills even if we used merge commits.

@bjlittle pointed out that rebasing would become very difficult if we used merge commits, but we realised that PR branches could still be updated via merge commits.

@rcomer confirmed that the Merge button remembers whatever setting you used last, so there isn't a way to have opt-in merge commits, outside of perhaps a GHA bot that could be commanded by a comment. We considered the risks introduced by accidental merge committing being possible, and how difficult it would be to undo.

@rcomer informed us that MPL use merge commits, and that maintainers often insist on people squashing WIP commits before they are willing to merge.

This seemed to come down to how much competence we expect of an Iris maintainer - both in experience with Git, and in attentiveness before pressing Merge.

[rcomer]

MPL use merge commits, and that maintainers often insist on people squashing WIP commits before they are willing to merge.

More encourage people to to squash. Squash merge is used when contributors are inexperienced (and any other contributor who says they prefer that).

[rcomer]

I think this has been answered.