Re: [PATCH v8] ls-files: introduce "--format" option
- From
ZheNing Hu <adlternative@gmail.com>
- Date
- Jul 22, 2022, 06:44 UTC
- Message-ID
- <CAOLTT8RjLoooT7t+ucFqa9P=8TiVL3M+ZgcEY7qVhRbjB=9OhA@mail.gmail.com>
- In-Reply-To
- <xmqqbktj3ct7.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> 于2022年7月21日周四 01:37写道：
Show 14 quoted lines
>
> > + 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.
Show 19 quoted lines
> > +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'?
Show 6 quoted lines
> I do not know if the $format I wrote without looking at the doc is > correct, but you get the idea. > > Thanks. > >
Thanks