It doesn't really work like that because a branch does not have a clear, canonical start point in gits history; every branches history goes all the way back to the initial repo commit. You can do some fooling around with diffing the merge parents to try and get some idea of the changes, but it's going to show all the differences (what changes are on master but not on the branch).
Having a single atomic commit to "add feature x" is a lots cleaner when you're git blame'ing then git show'ing the commit, as you get to see the whole picture, instead of a log message like "fixing typo" and a 1 character diff.
That said, this should definitely be done off on a branch, and there's no reason not to have multiple useful commits on a branch merged in as such, but trashy typo/forgot to add X style commits are completely worthless to someone looking back at history
What if when you git merge a branch into master, it collapses all the branch commits into a single commit that appears on the master branch, but the branch commits can still be viewed as being contained within the merge commit?
Meaning you could expand a the merge, see the branches that were merged into the branch, and the individual commits made on that branch.
Having a single atomic commit to "add feature x" is a lots cleaner when you're git blame'ing then git show'ing the commit, as you get to see the whole picture, instead of a log message like "fixing typo" and a 1 character diff.
That said, this should definitely be done off on a branch, and there's no reason not to have multiple useful commits on a branch merged in as such, but trashy typo/forgot to add X style commits are completely worthless to someone looking back at history