Am 08.05.24 um 17:25 schrieb phillip.wood123@xxxxxxxxx: > Hi René > > On 06/05/2024 19:23, René Scharfe wrote: >> Am 05.05.24 um 17:25 schrieb Phillip Wood: >>> Merge strategies are expected to exit 0 on success, 1 when there are >>> conflicts and another non-zero value for other errors - it would be >>> nice to do something similar here where 1 means "there were >>> differences" but it is probably too late to do that without a config >>> value to indicate that we should trust the exit code. >> Right, such a diff command protocol v2 would not need to pipe the >> output through an inspection loop. Sounds like a good idea. It's >> unfortunate that it would increase the configuration surface, which is >> not in an acute need to expand. We could advertise the new option when >> dying due to the unsupported combination of --exit-code and external >> diff, but that's in equal parts helpful and obnoxious, I feel. > > Yes, diff dying would be annoying but the message would be useful. Having poked at it a bit more, I wonder if we need to add some further nuance/trick to avoid having to reject certain combinations of options. Currently external diffs can't signal content equality. That doesn't matter for trivial equality (where content and mode of the two files match), as this case is always handled by the diff machinery already. Only lossy comparisons (e.g. ignoring whitespace) even have the need to signal equality. If we (continue to) assume that external diffs are lossless then we don't need to change the code, just document that assumption. And add a way to specify lossy external diffs that can signal whether they found interesting differences, to address the originally reported shortcoming. Is there an official term for comparisons that ignore some details? "Lossy" is rather used for compression. Filtered, partial, selective? > Thinking about the external diff and some of the other diff options I > wonder what we should do when options like "--quiet" and > "--name-only" are combined with an external diff (I haven't checked > the current behavior). If we introduced a diff command protocol v2 we > could include a way to pass through "--quiet" though maybe just > redirecting the stdout of the external command to /dev/null and using > the exit code would be sufficient. The current code uses shortcuts like that. For lossy external diffs we need to turn (some of) them off. Lots of possible combinations with special handling -- needs lots of tests for reasonable coverage. :-/ > P.S. I haven't forgotten about our unit-test discussion but I'm > afraid it will probably be the middle of next month before I have > time to reply. No worries; reminds me to polish some unit-test patches, though. I get distracted a lot these days.. René
