ls-tree: fix expansion of repeated %(path)

Commit Message

René Scharfe Jan. 14, 2023, 2:37 p.m. UTC

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 <[e-mail]>
---
 builtin/ls-tree.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--
2.39.0

Comments

Junio C Hamano Jan. 14, 2023, 4:46 p.m. UTC | #1

René Scharfe <[e-mail]> 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 <[e-mail]>
> ---
>  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)?

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 ;-)

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)" \
 	""

René Scharfe Jan. 14, 2023, 6:24 p.m. UTC | #2

Am 14.01.2023 um 17:46 schrieb Junio C Hamano:
> René Scharfe <[e-mail]> 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 <[e-mail]>
>> ---
>>  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)" \
>  	""

Patch

diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
index c3ea09281a..120fff9fa0 100644
--- a/builtin/ls-tree.c
+++ b/builtin/ls-tree.c
@@ -98,9 +98,11 @@  static size_t expand_show_tree(struct strbuf *sb, const char *start,
 		const char *prefix = chomp_prefix ? ls_tree_prefix : NULL;
 		struct strbuf quoted = STRBUF_INIT;
 		struct strbuf sbuf = STRBUF_INIT;
+		size_t baselen = data->base->len;
 		strbuf_addstr(data->base, data->pathname);
 		name = relative_path(data->base->buf, prefix, &sbuf);
 		quote_c_style(name, &quoted, NULL, 0);
+		strbuf_setlen(data->base, baselen);
 		strbuf_addbuf(sb, &quoted);
 		strbuf_release(&sbuf);
 		strbuf_release(&quoted);
@@ -144,7 +146,6 @@  static int show_recursive(const char *base, size_t baselen, const char *pathname
 static int show_tree_fmt(const struct object_id *oid, struct strbuf *base,
 			 const char *pathname, unsigned mode, void *context UNUSED)
 {
-	size_t baselen;
 	int recurse = 0;
 	struct strbuf sb = STRBUF_INIT;
 	enum object_type type = object_type(mode);
@@ -164,12 +165,10 @@  static int show_tree_fmt(const struct object_id *oid, struct strbuf *base,
 	if (type == OBJ_BLOB && (ls_options & LS_TREE_ONLY))
 		return 0;

-	baselen = base->len;
 	strbuf_expand(&sb, format, expand_show_tree, &data);
 	strbuf_addch(&sb, line_termination);
 	fwrite(sb.buf, sb.len, 1, stdout);
 	strbuf_release(&sb);
-	strbuf_setlen(base, baselen);
 	return recurse;
 }