]> git.ipfire.org Git - thirdparty/git.git/commit
cat-file: handle trivial --batch format with --batch-all-objects
authorZheNing Hu <adlternative@gmail.com>
Thu, 3 Jun 2021 16:29:25 +0000 (16:29 +0000)
committerJunio C Hamano <gitster@pobox.com>
Thu, 3 Jun 2021 22:50:26 +0000 (07:50 +0900)
commite16acc80a78ae5e931b94e861aff53a4af485f77
tree0f13af6a0ae9f608f0964ba2f5da5ba3d4b975f1
parent94f6e3e283f2adfc518b39cfc39291f1c2832ad0
cat-file: handle trivial --batch format with --batch-all-objects

The --batch code to print an object assumes we found out the type of
the object from calling oid_object_info_extended(). This is true for
the default format, but even in a custom format, we manually modify
the object_info struct to ask for the type.

This assumption was broken by 845de33a5b (cat-file: avoid noop calls
to sha1_object_info_extended, 2016-05-18). That commit skips the call
to oid_object_info_extended() entirely when --batch-all-objects is in
use, and the custom format does not include any placeholders that
require calling it.

Or when the custom format only include placeholders like %(objectname) or
%(rest), oid_object_info_extended() will not get the type of the object.

This results in an error when we try to confirm that the type didn't
change:

$ git cat-file --batch=batman --batch-all-objects
batman
fatal: object 000023961a0c02d6e21dc51ea3484ff71abf1c74 changed type!?

and also has other subtle effects (e.g., we'd fail to stream a blob,
since we don't realize it's a blob in the first place).

We can fix this by flipping the order of the setup. The check for "do
we need to get the object info" must come _after_ we've decided
whether we need to look up the type.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: ZheNing Hu <adlternative@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/cat-file.c
t/t1006-cat-file.sh