I think an Bram errs when he thinks that his experience in studying and experimenting with merge algorithms gives him deeper insight than the apparent newcomer to the field, Linus.
What he's missing is that Linus has spent a large part of nearly two decades doing merges using a variety of inadequate tools which no doubt frequently forced him to hand-edit many thousands of patches in order to get successful merges. When Linus sat down to start his two-week project, he brought with him an incredibly rich base of experience with real-world merging of changes in a significant, complex codebase with large numbers of contributors. Also, he's an insightful guy. So while he may not have spent as much time in formal study of the esoteric intricacies, Linus had great insight into the day-to-day issues that merge-heavy development processes create, and how to solve them.
And more importantly he had seen so many thousands of conflicts that he realized the futility of a smart algorithm significantly reducing the pain. Think about it, a bad automated merge probably causes as much pain as is alleviated by 10 trivial merge resolutions.
I completely agree but you are not extreme enough - I would rather have 100 trivial manual merge resolutions than 1 bad automated merge. You might not even notice your bad automated merge and that gets to be serious badness.
I do too, and as someone who has just started using Git... the error messages need some help. Luckily, it's open source, so I decided to take a look and see if I could improve them... unfortunately, they are hard-coded into the source, and not in some central location, making it very difficult to change.
You're still thinking like a developer (like Bram) by emphasizing the merging algorithm too much. It wasn't Linus's experience merging that helped him design the superior software. It was all the rest of his project-management experience, which helped him realize the role of merging within the broader system.
I think an Bram errs when he thinks that his experience in studying and experimenting with merge algorithms gives him deeper insight than the apparent newcomer to the field, Linus.
Whatever the value of years of experience, it's foolish to disregard the cost of bias those years build, also.
What he's missing is that Linus has spent a large part of nearly two decades doing merges using a variety of inadequate tools which no doubt frequently forced him to hand-edit many thousands of patches in order to get successful merges. When Linus sat down to start his two-week project, he brought with him an incredibly rich base of experience with real-world merging of changes in a significant, complex codebase with large numbers of contributors. Also, he's an insightful guy. So while he may not have spent as much time in formal study of the esoteric intricacies, Linus had great insight into the day-to-day issues that merge-heavy development processes create, and how to solve them.