Keeping the "intention" of the changes in the system only works if you actually bother to record or annotate the intention while making the commit.
If your idea is to use heuristics to automatically infer intention during commit time and record it into the system, then obviously you can also do that in git after the fact by comparing two commits and running the same heuristic.
In most cases (except file move?), I doubt the intention of the changes are so easily/cleanly captured. You'll probably need to have some deep IDE integration (eg. so it knows you actually renamed all your variables using the refactor tool). I can't see that having widespread application at all.
Simple thing that gets lost: someone adds very long comment on one line (maybe has word wrapping on); someone formats the comment to be on multiple lines; diff will be a mess even if there is no text difference in the actual comment.
One thing to investigate would be to include AST (abstract syntax tree) concepts in the source control or tools (although for comments might not solve the issue). Renaming a variable, moving a function around and other cases would be caught by an AST aware source control, but they are not today.
If your idea is to use heuristics to automatically infer intention during commit time and record it into the system, then obviously you can also do that in git after the fact by comparing two commits and running the same heuristic.
In most cases (except file move?), I doubt the intention of the changes are so easily/cleanly captured. You'll probably need to have some deep IDE integration (eg. so it knows you actually renamed all your variables using the refactor tool). I can't see that having widespread application at all.