I was reviewing a PR today and have to disagree with you. There was a single value change in a jsonl test data file. This is nightmarish to read in regular git diffs, as the change gif thought was happening was (with text wrapping) an full page worth of json rather than identifying it was a single word change. And because it is jsonl, the file could not be split into different lines without altering it’s semantics.
I don’t think it’s unreasonable we could be a little smarter here.
Other tools exist, of course, but if you're going to be shipping around stuff that `git apply` or thousands of other tools can handle, it has to be in "the" standard format.
Imagine doing code review in a language where every function had to be written on one line!
The two techniques I use to dodge this:
1/ Switch from JSONL to a list of objects then pretty print it to be line oriented.
2/ Compress the test data to discourage viewing it altogether, and make people describe what’s being changed rather than leaving it up to the diff to show it.
Edit: Worst is diffing yaml files, you really need a stable way to parse those.
If I have func add() and main() inside of my first file, main() calling add(), and then I decide to move add() into its own file, nothing else.
What has actually changed and what is relevant to the developer? An ideal tool would give me two pieces of information:
1) most importantly and obvious: the add function has been moved out of main into a new file
2) to save me the time of wondering what else has changed, it should also recognize and tell me upfront that the code is materially the same
Line diffs would just show a bunch of adds and deletions which is good enough to not miss the change I guess , but not enough to tell you quickly what happened. Obviously this is a simple example.
I agree however that while Pijul is technically very interesting, it doesn't seem to have any killer features that would overcome the cost of switching to a niche version control.