Yes, losing the detailled history of each individual change is a downside of this approach.
It could be mitigated to some extend by copying the commit messages into the squashed commit. That just requires a bit more work (and paying attention) on merge, but it’s not hard to do.
This won’t break the change down in constituent commits, though. But for this, we can look at the pull request history. And that’s where you can find lots of information about how the change came to be the way it is. That and the related issue, of course. The fact is, this information lives on GitHub and can’t be easily ported into git. Nor would I expect that to be very helpful because many of these discussions are not very important to look up in the long term.
Permanently relevant information about implementation choices should rather be written as code comments, not in the commit message.
Then you have that in code, the commit message to describe the result of the change and the PR/issue discussions for full background information.
I think this model works reasonable well. At least it seems to fit better than any alternative. I was at first sceptical, when we discussed to squash merge only. But I have come to realize its value.
This model should also apply to other repositories in crystal-lang. I’m pretty sure we’re using it in shards.