A well-crafted commit history for a merge conveys useful information and makes reviewers’ jobs easier by splitting a large change set into smaller logical chunks that are easier to reason about.
If the extra “noise” bothers you you can use —-first parent with git log.
For more than 15 years of Git usage I've never seen a well crafted commit history for a single PR. It either a series of well crafted multiple PRs with separate reviews or a brain dumpster fire of multiple commits trying to make it work.
Comments
A well-crafted commit history for a merge conveys useful information and makes reviewers’ jobs easier by splitting a large change set into smaller logical chunks that are easier to reason about.
If the extra “noise” bothers you you can use —-first parent with git log.
This wouldn't affect what the reviewer sees because the squash commit only happens after the PR is complete and is being merged to master
For more than 15 years of Git usage I've never seen a well crafted commit history for a single PR. It either a series of well crafted multiple PRs with separate reviews or a brain dumpster fire of multiple commits trying to make it work.
Well I have seen them. It’s your anecdata vs my anecdata :)
If you have public GH contributions you could show examples of PRs with stories told by commits and my anecdata would be invalid :)