[PATCH] cat-file: handle content request for --batch-command without type

[Jeff King <peff@peff.net>]

On Tue, Jul 28, 2026 at 10:08:46AM +0100, Alan Stokes wrote:

> > > Do you want to try your hand at a patch? It would need to do the
> > > save/restore, and most importantly add a new test to t1006.
> 
> I would be willing to have a go at it. But realistically I probably won't have
> time for a month or two. I'm also a complete noob at the whole posting
> patches via email process, so it may be slightly chaotic. If anybody else
> wanted to deal with it I obviously wouldn't object.

That's long enough that I'm worried we'll forget about it. So here's a
patch. Thanks very much for a clear bug report!

-- >8 --
Subject: cat-file: handle content request for --batch-command without type

The batch mode of cat-file needs to know the object's type in order to
print the contents (because it decides whether to stream or not based on
object type). The default batch output contains %(objecttype), so we get
the type info automatically. But when it doesn't, we have to ask for it
explicitly.

In the --batch code path, we check while setting up the object_info
struct whether we will print the contents, and if so set "typep" to get
the value. This comes from 6554dfa97a (cat-file: handle --batch format
with missing type/size, 2013-12-12).

But later we added a --batch-command mode, which does not do the same
trick. The decision about whether to retrieve the contents is made
per-command (a "contents" vs "info" command), so we can't decide when
building the object_info originally. As a result, asking for:

  echo "contents HEAD" | git cat-file --batch-command="%(objectname)"

will fail the assertion in print_object_or_die() that the type was
actually filled in.

We can fix it by tweaking the object_info on the fly as we receive each
command. But we should be careful to restore it afterwards; otherwise a
sequence of commands like:

  contents $one
  info $two
  info $three

will pay the type-lookup price for $two and $three when it does not need
to. This wouldn't be incorrect, but just slightly inefficient (and hence
there are no tests for that part, because the externally-visible
behavior is the same).

Reported-by: Alan Stokes <alan@source.dev>
Helped-by: Pablo Sabater <pabloosabaterr@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
 builtin/cat-file.c  | 3 +++
 t/t1006-cat-file.sh | 8 ++++++++
 2 files changed, 11 insertions(+)

diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 1458dd76d6..ac458c9737 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -689,8 +689,11 @@ static void parse_cmd_contents(struct batch_options *opt,
 			     struct strbuf *output,
 			     struct expand_data *data)
 {
+	enum object_type *saved_typep = data->info.typep;
+	data->info.typep = &data->type;
 	opt->batch_mode = BATCH_MODE_CONTENTS;
 	batch_one_object(line, output, opt, data);
+	data->info.typep = saved_typep;
 }
 
 static void parse_cmd_info(struct batch_options *opt,
diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index 762c77c351..f085738082 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -1351,6 +1351,14 @@ test_expect_success 'batch-command flush without --buffer' '
 	test_grep "^fatal:.*flush is only for --buffer mode.*" err
 '
 
+test_expect_success 'batch-command contents auto-handles type' '
+	echo "HEAD" |
+		git cat-file --batch="%(objectname)" >expect &&
+	echo "contents HEAD" |
+		git cat-file --batch-command="%(objectname)" >actual &&
+	test_cmp expect actual
+'
+
 perl_script='
 use warnings;
 use strict;
-- 
2.55.0.749.g30c495c7a6