When it comes to Git history, less is more
On one hand, I agree that these are all good points. I haven’t ever played with kernel code, but I have tried to backport years-old Glibc commits and it’s an absolutely miserable experience because “minor” things like small-scale reformatting would frequently be bunched together with unrelated changes. They also maintained their configure script in version control and apparently even merged it manually, because I’ve found that at many points in its history it would be composed of pieces generated by different versions of autoconf.<p>On the other hand, I don’t think that the conclusions of this story are as inevitable as it makes them seem. Much of the pain it describes is due to the fact that Git is, as it proudly  itself, <i>stupid</i>: it doesn’t understand that your spacing or line breaking or bracketing changes are incidental to what the code is trying to accomplish. I’m not saying that structural or otherwise language-aware editing or source control is the silver bullet because I’m well aware that so far most attempts at it suck, but I think it’s important to remember that whitespace pedantry is to a large extent a tooling issue.<p>Could a merge tool coupled less than completely to clang-format (or yapf, or black, or gofmt ...) use its settings to improve the merges, I wonder?<p>(Tangentially related: Monticello, Paredit, the “skeleton syntax tree” idea from Dylan.)