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

[ZheNing Hu <adlternative@gmail.com>]

Junio C Hamano <gitster@pobox.com> 于2022年7月21日周四 01:37写道：
>
> >       +       git commit -m base
> >       +'
> >       +
> >       +test_expect_success 'git ls-files --format objectmode v.s. -s' '
> >      -+       git ls-files -s | awk "{print \$1}" >expect &&
> >      ++       git ls-files -s >files &&
> >      ++       cut -d" " -f1 files >expect &&
>
> Either "awk" or "cut" is fine and flipping between them is a bit
> distracting.  Cutting the pipe into two is a good move.
>
> But is this testing the right thing?
>

Yes, I am sure about that cut can do the same thing as awk, and it can
specify its delimiter.

> > +test_expect_success 'git ls-files --format objectmode v.s. -s' '
> > +     git ls-files -s >files &&
> > +     cut -d" " -f1 files >expect &&
> > +     git ls-files --format="%(objectmode)" >actual &&
> > +     test_cmp expect actual
> > +'
>
> It only looks at the first column of the "-s" output, and we are
> implicitly assuming that the order of output does not change between
> the "-s" output and "--format=<format>" output.  I wonder if it is
> more useful and less error prone to come up with a format string
> that 100% reproduces the "ls-files -s" output and compare the two,
> e.g.
>
>         format="%(objectmode) %(objectname) %(stage)    %(path)" &&
>         git ls-files -s >expect &&
>         git ls-files --format="$format" >actual &&
>         test_cmp expect actual
>

See test case: 'git ls-files --format imitate --stage' which just do such thing,
maybe I should change its name to 'git ls-files --format v.s. -s'?

> I do not know if the $format I wrote without looking at the doc is
> correct, but you get the idea.
>
> Thanks.
>
>

Thanks