Re: [PATCH v1 1/7] t1005: assert output of ls-files

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

 



On 14/03/2023 09:51, Michael J Gruber wrote:
Andrei Rybak venit, vidit, dixit 2023-03-12 21:15:13:
  t/t1005-read-tree-reset.sh | 15 ++++++++++-----
  1 file changed, 10 insertions(+), 5 deletions(-)

[...]

Just in case someone else was wondering, too:

All these subtests write to `expect` just before the provided context
lines, so there indeed is something to compare to, and it is the output
of `git ls-files -s` before any changes and resets. As a consequence,
these subtests checked only removal of remnants in the woring tree
before the patch, and they check removal of index bits after the patch
(additionally).

Looks fine to me - though one could probably use `git ls-files -s -o` or
such instead, the suggested version is more "explicit".

Thank you for reviewing this.

None the tests (both in t1005 and other files) use this combination of flags
for `ls-files` right now.  Checked using:

    $ git grep 'ls-files.*[^a-z-][-][os][^|]*[^a-z-][-][so]' || echo none
    none
    $ git grep -E 'ls-files .* --(stage|others)'
    Documentation/git-ls-files.txt:'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
    contrib/hg-to-git/hg-to-git.py:    os.system('git ls-files -x .hg --others | git update-index --add --stdin')
    t/t1092-sparse-checkout-compatibility.sh:       git -C sparse-index ls-files --sparse --stage >cache &&
    t/t1092-sparse-checkout-compatibility.sh:       git -C sparse-index ls-files --sparse --stage >cache &&
    t/t1306-xdg-files.sh:    git ls-files --exclude-standard --ignored --others >actual) &&

In this topic, I plan to focus on just fixes of unused files and to leave
flags of `git ls-files` as is for now.



[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