Re: [BUG] "echo HEAD | git cat-file --batch=''" fails catastrophically

[Jeff King <peff@peff.net>]

On Tue, Dec 10, 2013 at 11:37:14PM -0500, Samuel Bronson wrote:

> % echo HEAD | git cat-file --batch=
> 
> fatal: object fde075cb72fc0773d8e8ca93d55a35d77bb6688b changed type!?
> 
> Without the =, it works fine; with a string that has both
> "%(objecttype)" and "%(objectsize)", it's fine; but when you don't
> include both, it complains about one of the values that you did not
> mention having changed.
> 
> jrnieder fingered v1.8.4-rc0~7^2~15 as the (likely?) culprit here.

It's not actually that commit itself, but rather that commit in
conjunction with further optimizations in that patch series.

The rest of the series tries hard to avoid looking up items that we
aren't going to print, for --batch-check. But I didn't think about the
fact that "--batch" got the same custom-header feature, but was relying
on the values from the default header to do its consistency checks.

The following patches should fix it.

  [1/2]: cat-file: pass expand_data to print_object_or_die
  [2/2]: cat-file: handle --batch format with missing type/size

Doing "--batch=" is somewhat pointless. If you do not get the size, you
cannot know when the object content ends, so it only makes sense with a
single object. At which point using --batch is pointless. Doing
"--batch=%(objectsize)" is reasonable, though, and that is broken, too.

v1.8.4 has the breakage, though it's not a regression (doing
"--batch=anything" did not exist before that). This can probably just go
to the regular "maint" track for v1.8.5).

-Peff