It's analogous to how the difference between 5 and 15 is equal to the difference between 105 and 115.
Patches are torsors? :o
The result of a diff is... a nebulously defined concept that somehow describes the changes. It's not clearly (to me) defined which parts of the files are considered to part of the diff and which parts are to be excluded.
A diff shows the difference between two commits (i.e. snapshots). Perhaps a better math analogy: one point can be subtracted from another to give a vector.
> It's not clearly (to me) defined which parts of the files are considered to part of the diff and which parts are to be excluded.
You're right that it's not precisely defined in that way, but there's a good reason for this.
If you move the top line of a file to the bottom, should the diff tool show you that one line was deleted and one new line was added (i.e. that one line having been moved), or should it show all the other lines in the file as having been deleted and re-added in a different place? Both are valid interpretations of the difference between the two snapshots, but of course a real-life diff tool will show the former, as that's what's helpful to the user.
Git is based on the idea that it is generally safe to do that. You can't do any kind of work with git other than commits on your own local repo without relying on diffs and merges based on diffs.
Sure, I see your point as it applies to cherry-picks/rebasing. Yes, there's no formal guarantee it will do as you expect. The user should always check it manually. Occasionally it doesn't do what you want.
I'm of the opinion git cherry-pick should default to behaving like git cherry-pick --no-commit for that reason.
edit:
> they don't always produce the most sensible result
I don't know how much work has been done on language-aware diff/merge algorithms, but I can't see an obvious reason for it to be a dead-end.