I respect the hell of those philosophies because of how far Linux and git have made it, which they've done by winning people over with good, solid choices. I would hope I'd be a good enough engineer to make the same choices if I saw the same things Linus saw 20 years ago. But it's 20 years later and I'm looking at the next 20 years and I see a different landscape and it causes me to have a different outlook. I think code literacy is a hugely important right now as a battle is fought over whether people will own their technology.

If many people are literate in code, the likelihood is far greater that they will own the tech and it will be open source and built according to principles that make software accountable to them. If most people are illiterate in code, they will become subjects to proprietary technology forced to use products which they have no control over.

The problem is that code literacy hasn't moved beyond the era where developers are people who own a physical keyboard and a full-size computer monitor, use a filesystem regularly, and are able to install and run native applications on their laptop or desktop. But here you've got the next generation of programmers who need to become literate in code (so that they won't become subservient to it) and for many all they have are touchscreens: phones and tablets. Maybe they're on a shared device where they can't or don't want to install software. They might not know what a filesystem or x86 machine code is. That's why I'm on mission to make code literacy and the ability to contribute to open source a matter as simple as having a screen and a browser.

To reply more directly to the difference in philosophy around merging diffs, I think the git philosophy on preferring to expose potential conflicts rather than glossing over them is basically exactly right, because it creates a system to resolve ambiguity by capturing user intent. If I have any complaint it's that some types of ambiguities are not captured because they are not the result of textually overlapping changes. The canonical example would be a scenario where one developer renames a function and another adds a new usage of it. Git can see no text conflict and so it glosses over the semantic problem. A semantic system would be able to expose not only all the potential conflicts/ambiguities that git can see, but also some that it cannot. And in the case of an add/rename conflict the system should just handle it because the semantic intent of each change was recorded in the system: not "change these 8 call sites" but "change every site that calls this function."