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

From: Jeff King <peff@peff.net>
Date: Dec 11, 2013, 11:54 UTC
Message-ID: <20131211115458.GA10561@sigill.intra.peff.net>
In-Reply-To: <CAJYzjmdHdLZaBijahepOQDJtDd_TdojT4ivNxGrcerRfEuHQEg@mail.gmail.com>

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

Show 10 quoted lines

> % 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