Re: [PATCH v8] ls-files: introduce "--format" option
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 25, 2022, 01:03 UTC
- Message-ID
- <xmqq7d4280m8.fsf@gitster.g>
- In-Reply-To
- <CAOLTT8RqMU-k85LmcpY0wATHSDoWDEQLnPtfuZ2OC2nWN9305A@mail.gmail.com>
ZheNing Hu <adlternative@gmail.com> writes:
Show 9 quoted lines
>> That was not the point. By extracting only "%(objectmode)" without >> having any other clues (like "%(path)") on the same line, the test >> is assuming that ls-files will always sort its output in the same >> order regardless of the output format, whether it is "--stage" or >> "--format=<spec>", and that was what the "is this testing the right >> thing?" question was about. >> > > Ah, so that we should sort the ls-files output first, and then compare them.
Imagine that there are three paths in the index and "ls-files -s" gives
100644 1234... 0 path1
100644 2345... 0 path2
100755 3456... 0 path3but a bug causes "ls-files --format=<spec>" to show entries in a wrong order, e.g. first for path2 and then for path1 and then for path3. If the test used enough fields (like the one that mimics the full output of "ls-files -s"), then the output may be
100644 2345... 0 path2
100644 1234... 0 path1
100755 3456... 0 path3and you would notice that it is different from "ls-files -s".
But if the test only used %(objectmode), then the faulty output from "ls-files --format=%(objectmode)" would be
100644
100644
100755that matches the "ls-files -s | cut -d' ' -f1"
If you sort, then such a breakage will become even harder to notice. If the faulty output showed path3 first and then path2 and then path1, the raw output from "ls-files --format=%(objectmode)" may be 100755/100644/100644, but if you sort it, no matter what the broken order is, you will always get 100644/100644/100755.
So, no, we shouldn't sort. If ls-files were allowed to show output in any random order, then sorting the output before comparing is a good strategy, but that does not apply here.