Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> > Why not use "git diff --no-index --ignore-cr-at-eol"? Do you even need >> > to wrap it? >> >> Hmph. That surely sounds sensible if it works, and I offhand do not >> see why it shouldn't work. > > Is this a reversal of the stance you took in your reply in > https://lore.kernel.org/git/7vps7xrfxa.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/ to my > suggestion to replace `cmp` by `diff --no-index` (in that mail referred to > as patch [7/8])? cox.net? It is a lifetime ago and the world has changed. Hopefully that "diff --no-index" has matured a lot to earn more confidence by us than it had back then. > If I recall correctly, you clarified outside of that thread that "I do not > think it is a good enough reason to make the tests slower" was you being > concerned about employing the entire diff machinery instead of doing a > simple byte-for-byte comparison. Is it still relevant, now that we are talking about text-cmp that ignores cr-at-eol, to bring a random remark about byte-for-byte comparison from more than 10 years ago? > Just because it is easier to review a one-liner to switch from essentially > `cmp` to `git diff --no-index --ignore-cr-at-eol` does not mean that it is > reasonable: it would cause us to blast out that much more CO2, just for > our one-time convenience. Measurement, in tons per year, is needed, or please stop talking about CO2. It is not that funny. Developer cycle time is easier to measure and more meaningful. It would be much faster to run a byte-for-byte-with-ignore-cr-at-eol comparison than running "diff --no-index --ignore-cr-at-eol" on files with meaningful sizes. But comparison between "expect" and "actual", which are typically at most several lines long? Wouldn't the overhead to spawn a process dwarf everything else, especially on Windows, whether it is your byte-for-byte-with-ignore-cr-at-eol program or "git diff"?
