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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> 于2022年7月25日周一 09:03写道:
>
> ZheNing Hu <adlternative@xxxxxxxxx> 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.

I get what you mean. So test 'git ls-files --format imitate --stage'
can help for
checking it, because every line content is different (maybe different <path>,
or the same <path> with different <stage>,<objectmode>...), we can find the
--format "disorder bug" with ease.

ZheNing Hu




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux