[vsareto]

>Your commit message should have a short title explaining the change and the body should go into as much detail as necessary into why the change took place, I can see the what from looking at the diff.

That sounds tedious like commenting every line of code. You might have to do this if the code is hard to read and maintain though. Most of the time the why is "because feature X demands that it change".

Maybe it's just me, but I prefer squashed merges because lots of small commits are also annoying to switch between and if I'm diving into git history, I'm investigating and have some extra time to understand everything instead of relying on commit messages.

[martijnvds]

Try reading the git logs of some of the bigger open source projects (especially the Linux kernel).

Those really show why those commit messages are useful to figure out why things were done the way they were ("what the dev was thinking"). This is especially useful if some kind of bug is found 2 years later and someone who wasn't involved in the original change needs to fix it.