[pdimitar]

I'd be very surprised if you used such a feature on a daily basis indeed.

I understand the rationale but the balance tilts too far into the "too much details" territory for me and that can slow me down while digging.

What I found most productive for myself is that searching for a problematic piece should happen on a two-tiered tree, not a flat list. What I mean is: first find the big squashed PR commit that introduces the problem, then dig in more details inside of it.

Not claiming my way is better but for almost 20 years of career I observed it was good for many others as well, so I am not exactly an aberration either.

To me a very detailed history is mostly a distraction. Sure `git-bisect` works best on such a detailed micro-history but that's a sacrifice I am willing to make. I first use bisect to find the problematic squashed commit and then work on its details until I narrow down the issue.