Is this what most people do? And is this something you can turn off with Git Town? I don't like to to squash-merge, I spend time making sure my commits are as much logical and self-contained units as they can be in my branches, and I want to preserve the ability to revert and/or bisect them later.
I would have assumed that a regular (not squashed) merge is more common, and easier to do, because it's the default behavior of "git merge". It takes extra git commands and/or extra non-default arguments to git merge to get a squash merge. My GitHub also doesn't default to squash merge, IIRC... Don't you have to choose squash merge or be told to use it, if you don't otherwise know or care?
My usage is to commit very frequently, like whenever I make a non-trivial fix or small refactor, or when something that touches several files compiles cleanly, or passes a unit test. This is several commits per day. It's practically every file save (if you remember filesystems with explicit version support). So my commit history is very noisy.
When I push back to a shared repo, I want the commit history to document what the change is; various false or partial paths are not enlightening (if I planned to follow strategy 'X', found it did work, and backed out and used algorithm 'Y' then that should go in the source as a comment, not in the metadata.
If my check ins were once a day I might not want to lose them. So I'm philosophically aligned with you, but my commits are so high frequency that the merge functions as a low-pass filter.