> This wouldn't be an issue if patches were XML or JSON with a well defined schema, but everything must be a boutique undocumented format in the world of Unix tools.
Patch files are readable by humans. Replacing them with XML or JSON would fix this problem, but at the expense of removing a core feature.
If, by "readable by humans", you mean "it would reliably fool humans as well", I'd say it's an ambiguity bug regardless of whether it's "a core feature" or not. A patch format, human-readable or not, should clearly indicate which part is the commit message and which part is an actual diff; it's not the case here.
Alright, allow me to disambiguate in your preferred format.
that's not the preferred format for writing XML, this is:
What I posted is valid XML. And even prettified, it's a pain to read.
it was valid but not the way XML is written or read by humans which is what we are discussing. how much of a pain it is to read is a matter of taste. i won't deny that. but XML can be made more readable without fail because it is a structured format. i would not have been ale to reformat a patch text the way i reformatted this XML example. XML is also more powerful. it could handle word based changes, as opposed to patch which can only do line based changes. same goes for JSON. patch could potentially be improved, but i don't see how it could handle word based changes without extra syntax to mark line breaks.
That's really not that bad, especially with indentation and color coding. You're kind of cheating by putting it into HN, which is terrible for code.
> XML is painful for humans to read and write.
Speaking of claims no-one made; no-one's talking about writing patch files by hand.
If that's good enough to be human readable than patch is even better.
People do write patch files be hand.
More commonly, edit them.