Am 14.01.2023 um 17:46 schrieb Junio C Hamano:
> René Scharfe <l.s.r@xxxxxx> writes:
>
>> expand_show_tree() borrows the base strbuf given to us by read_tree() to
>> build the full path of the current entry when handling %(path). Only
>> its indirect caller, show_tree_fmt(), removes the added entry name.
>> That works fine as long as %(path) is only included once in the format
>> string, but accumulates duplicates if it's repeated:
>>
>> $ git ls-tree --format='%(path) %(path) %(path)' HEAD M*
>> Makefile MakefileMakefile MakefileMakefileMakefile
>>
>> Reset the length after each use to get the same expansion every time;
>> here's the behavior with this patch:
>>
>> $ ./git ls-tree --format='%(path) %(path) %(path)' HEAD M*
>> Makefile Makefile Makefile
>>
>> Signed-off-by: René Scharfe <l.s.r@xxxxxx>
>> ---
>> builtin/ls-tree.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> I wonder if this was broken from its introduction at 455923e0
> (ls-tree: introduce "--format" option, 2022-03-23)?
Yes.
> It seems to be the case. With the following applied on top of
> 455923e0, the new test fails as expected, and your patch fixes
> the breakage, so I am tempted to squash the tests in ;-)
I didn't include a test because it's an odd bug which I didn't expect to
ever return. But its current existence proves that it can happen. So I
don't mind this addition.
>
> Thanks.
>
> t/t3104-ls-tree-format.sh | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git c/t/t3104-ls-tree-format.sh w/t/t3104-ls-tree-format.sh
> index 7f1eb699d3..7e6c4dc5da 100755
> --- c/t/t3104-ls-tree-format.sh
> +++ w/t/t3104-ls-tree-format.sh
> @@ -37,6 +37,12 @@ test_ls_tree_format () {
> '
> }
>
> +test_expect_success "ls-tree --format='%(path) %(path) %(path)' HEAD top-file" '
> + git ls-tree --format="%(path) %(path) %(path)" HEAD top-file.t >actual &&
> + echo top-file.t top-file.t top-file.t >expect &&
> + test_cmp expect actual
> +'
> +
> test_ls_tree_format \
> "%(objectmode) %(objecttype) %(objectname)%x09%(path)" \
> ""
