Re: [PATCH v8] ls-files: introduce "--format" option

[Junio C Hamano <gitster@pobox.com>]

ZheNing Hu <adlternative@gmail.com> writes:

>> 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 path3

but 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 path3

and 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
    100755

that 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.