[darekkay]

> IMO the pursuit of, or even a concept of 'clean history' is a fallacy and waste of time. It is a level of obsession which I think is just not worth it.

While I do obsess over a git clean history (at least in my personal projects), I still mostly agree. Doing rebase instead of merge to have a cleaner history (as in git log) might not be worth it (git log --no-merges will return a similar image). But there's one feature I use constantly that relies on not having any useless commits on it: git blame. Whenever I'm asking myself why a changes was made (at least weekly), I'm looking for the commit that introduced the change. Things like "fix typo" or "add missing files" don't help. Hence, I am doing a lot of amends and interactive rebases to combine changes that belong to each other. It may take 2 more minutes, but it will make my (and my collegues') life easier in the future.

[WorldMaker]

If you follow a PR heavy or PR only methodology heavy on meaningful merges with good descriptions, `git log --first-parent` can be more useful than `git log --no-merges`. It's more condensed and focused on high level features instead of the smaller baby steps that build up the high level. `git blame` also accepts `--first-parent`.

[wdfx]

Sure that's all fair enough. I'm not advocating being sloppy either - just be pragmatic about the effort/reward.