As well as writing good commit messages, I've previously written about not squashing commits when merging.
I think it's beneficial to keep the history of the commits that led to a change, especially if detailed messages have been written for some of the commits.
Typically, if the commits are squashed as part of a pull or merge request, the history and information is lost or all the messages are merged together - making them hard to read and, arguably, less valuable.
If you're working in a pair or mob and creating temporary commits on a short-lived branch, that's a situation when squashing commits is OK - as long as it's done properly.
I wouldn't have a generic automatically generated message.
I'd take the time to review the changes on the temporary branch and compare them to the mainline, remove any unrelated changes and write a new commit message that describes all the changes.
I'd make sure the new message is used and not lost when merged - especially when using online tools.
Then I can squash any temporary commits and merge the final squashed version.
