I think this depends on your policy. The policy at my work place is that every commit into master is always a merge commit. When looking at the git logs, we then always do:
git log --first-parent
This only shows the top level commits (either a direct commit or a merge commit) and doesn't show any of the subcommits in the branches.
This gives us a very clean history, something like:
commit ce29331f7da82ce528ca6e437b8893248a842169
Merge: a14522cbf 936ef9f90
Author: Joe Sample <joe.sample@example.com
Date: Tue Jul 7 14:34:20 2020 -0500
ISS-2047 - Add ids to user invitation or creation
commit a14522cbf32487dc590c8b6f3332d3fc9371a640
Merge: d08342170 cb94a86b1
Author: Jane Dow <jane.doe@example.com
Date: Tue Jul 7 14:28:28 2020 -0500
ISS-2032 - If an enterprise is disabled, their api keys should be disabled
commit d083421702e3ff50bc4c62e85b687e172e4bfe76
Merge: 0d167d25e ba3900a4a
Author: Joe Sample <joe.sample@example.com>
Date: Tue Jul 7 14:25:41 2020 -0500
ISS-2045 - Return a reason of why the invitation was auto-cancelled
Then if I want to see everything that happened in the branch that was merged in, I can just run:
and see all the commits that were in that feature branch. No need to squash things or hide them.
I really wish git, by default, showed commits under a merge as a tree, rather than as a flat list. This is what bazaar (bzr now breezy) did, and it made a lot more sense when looking at the history.
I don't get the "no merge commits" argument - git log has dozens of options allowing you to bend it to your use case.
To address the grand parent that "a clean history is has no merge commits" I would argue that a clean history is also a lie if you're working in a branching workflow (hint: you should be working in that most of the time).
If you want to avoid (note: not eliminate) merge commits then make sure to rebase against master before merging, and then ensure merges are fast-forward merges.
A 'merge commit' is the commit that ties together two strands.
* merge commit
|\
| * branch work
| |
| * branch work
|/
*
If you squash to merge, typically you're also going to rebase it (equivalently, if it's more familiar, cherry-pick the squash onto the branch your 'merging' it into).
* squash cherry-picked / rebased
| * both branch works squashed
| * | branch work
| | |
| * | branch work
|/_/
*
(In this case the target branch could have been fast-forwarded, but this also works if there's some other work on the mean time:)
* squash cherry-picked / rebased
|
* something unrelated
| * both branch works squashed
| * | branch work
| | |
| * | branch work
|/_/
*
