[conartist6]

To reply more directly to the difference in philosophy around merging diffs, I think the git philosophy on preferring to expose potential conflicts rather than glossing over them is basically exactly right, because it creates a system to resolve ambiguity by capturing user intent. If I have any complaint it's that some types of ambiguities are not captured because they are not the result of textually overlapping changes. The canonical example would be a scenario where one developer renames a function and another adds a new usage of it. Git can see no text conflict and so it glosses over the semantic problem. A semantic system would be able to expose not only all the potential conflicts/ambiguities that git can see, but also some that it cannot. And in the case of an add/rename conflict the system should just handle it because the semantic intent of each change was recorded in the system: not "change these 8 call sites" but "change every site that calls this function."

[franktankbank]

I suppose this canonical example would be papered over easily with minimal test coverage.

[conartist6]

Yeah it can be, but you'd really prefer to know without having to go do an exhaustive search I think. The closer to the root cause you catch the problem the easier it will be to tell what happened. Plus, it's not always easy to run exactly the right tests and to run them at exactly the moment they're needed. I usually won't run the whole test suite on each commit if I'm just doing a rebase, say, but it would still be nice if I didn't sail past a problem that I would later have to retrace my steps to fix.

[franktankbank]

The amount of code changes as seen in a git diff is roughly close to the amount of text changes. So reviewing is scaled linear with the change. In the way your are diffing are there any confounding changes? i.e. I make what seems like a small textual diff but it realigns the whole model of the code base that causes your diff to look like a big chunk of your code base is changed? Maybe that's a good thing? Just thinking out loud, I can't say I have an understanding about what your methodology is.

[conartist6]

The methodology is like a codemod or a lint rule. If you've worked with codemods you usually review a combination of the (small) script that describes the intent behind the changes you want and the (larger) diff of (text) changes that were generated by applying the codemod.