This!

There's value in both use cases: 1. Scrolling through the log to see an overview of the direction of the project on the level of complete features. 2. Being able to see exactly when, who, and why any single specific line was changed.

Squashing gives you 1, but throws out 2 on the way.

I like this a lot! Maybe way to add some metadata for a "commit collection" in git that is collapsed into a pseudo-commit by default (for browsing, bisect, blame, etc) but with the option to drill down/expand into sub-commits.

git already does this. The message for the merge commit contains the overview of what's happening in the commits in the merge, and use `git log --first-parent` to only include the merge commit when one is encountered.

That said, I still prefer squash/merge myself.

This would give the best of both worlds. People preferring the squash style can view the log cleanly, and people preferring detailed history can get detailed history.