[pfix]

Maybe it's my DevOps / System Engineering perspective, but most of the time when checking the history of the code, I care why a specific line changed - and squash commits don't help me get the granularity for that (e.g. why do we need 5 instead of 4 instances now) - most of the times, those changes are too small in the context of the full Pull Request / Merge, but matter 2 years later when you try to grok why something is the way it is.

So I prefer the flow of rebasing before merge. This way main stays linear and readable and you have the descriptive level at the commit level. The Context for the full merge can be found in the ticket corresponding to the change.

[cbovis]

"matter 2 years later when you try to grok why something is the way it is"

Sounds like the perfect use of an inline comment rather than change history?

[pfix]

True - but then I've seen way too many comments having no relation left to the code around them.

On the other hand the worst offenders are refactorings with the commit message "refactoring". Then you can go hunting. Then a comment would have helped.

In a perfect world we would have both, good inline comment, well written commit message and a ticket with more than a title.