I feel it is best to leave git out of this - separation of concerns Let external tools evolve independently instead.

Git doesn't store diffs on logical level. Git operates on snapshots of trees. Commit is not "a collection of changes", it's a snapshot of a tree with attached predecessor of it.

Then the another layer (which can be git, but also can be any other tool, adding custom diff tool to git is very easy) uses that to generate diffs.

There is zero stopping anyone from adding contextual diffs to Git. Just ask it for content of both commits and feed it to the algorithm.

Yes, git underneath stores data as diffs but they are only vaguely related to logical structure of commits

> Then the another layer (which can be git, but also can be any other tool, adding custom diff tool to git is very easy) uses that to generate diffs.

Linky: https://stackoverflow.com/questions/255202/how-do-i-view-git...

> Yes, git underneath stores data as diffs but they are only vaguely related to logical structure of commits

And that's why we call that lower level compression trick "delta", not "diff".

Interesting. Wonder if something like that can be used to make git cleverer about merges for example.

Git’s merge algorithm looks at three versions of the code: the two branch tips being merged, and their common ancestor. It might be better at resolving conflicts if it looked at some of the intermediate commits as well, but I don’t know of anything that does so.

Merge part isn't pluggable like that IIRC. Would be interesting if that was given stable interface, then supposed "smart merge" tool could iterate with few ways to merge code while running tests to check which one produces least/no errors