I'd prefer it not be magic. Just because git COULD merge two of the same line changes doesn't mean it SHOULD.

Maybe you have two vastly different methods to solving the same problem and now they are both in there and both not working instead of leaving it up to the merger to decide.

This seems like a clear case of unequal tradeoffs.

There are a couple of conflict patterns that are particularly easy to identify, which git could merge smoothly. For instance, two unrelated code blocks are appended to the bottom of the same file - whoever merged those two probably wants to keep both in any order.

But if you don't want that behavior, git is going to quietly auto-merge a bad change. That's easily 10x as bad as the time savings is good, maybe 100x. So I agree - this should not be magic, and I'm pretty sure the design for auto-merge hits practical limits long before technical ones.

How do you propose that be dealt with programmatically?

To be fair git could be given a tiny bit of "smarts" per language it's looking at. So say 2 different people add attributes to an HTML item it could use some sort of system that let's it run an HTML merge resolution routine that says "hey that's cool let me just combine those".

At the same time adding extra smarts like that, while providing a better UX when it works, the times where it doesn't work especially if you don't notice it stopped working in a specific way...that all scares me.

I'm not sure we're ready for smarts in our merging.

I posted this in a comment above but because it's relevant I feel it's worth putting here as well[1]:

git rerere (reuse recorded resolution): https://git-scm.com/2010/03/08/rerere.html

"it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you."

[1] This isn't explicitly against the rules but if it's in bad taste I'll happily remove it.

That's good if the exact same conflict reoccurs, but how often does that happen? What would be far better would be a syntax-aware version control system that knows about HTML attributes and understands how to combine two separate additions of HTML attributes.

That would be an improvement, although you’d still need human intervention sometimes. Even structurally sound merges can produce semantically wrong results, because diffs aren’t enough to reconstruct a correct history in all cases.

This is great, I appreciate you putting it here. I have a conflict pattern that comes up with enormous frequency at work, and for various reasons solving it somewhere other than the merge is not a great plan. It's always the same solution, though, and I could even predict it and flag for it in the commit message.

This seems like exactly the answer to that.

rerere is dangerous and not the solution. What I want is language-aware merge that can do things like "both these changes are just adding imports, adding in either order is fine" or "this change has added a parameter and this change has reformatted this line, I can add the parameter to the reformatted line".

ISTR darcs had something like this feature, but not as advanced as your idea. One of its types of patches was 'word substution', but you could imagine an 'add import' patch type.

Git supports external merge tools (per file type too). They don't need to be packaged with the base install IMO, and git won't support every language under the sun.

For example Unity3D are distributing one for their assets (which are not nice to merge as simple text)

For sure and I didn't mean they should necessarily be packaged with the base install either (though I'd argue as long as they're developed in a way that they can be updated you could provide a better UX bundling a few most common ones in). It's certainly doable though my only worry is them being almost smart enough and making a big mistake that isn't immediately noticeable.