Re: [RFC/PATCH 2/3] mailinfo: correct malformed test example

[Jonathan Tan <jonathantanmy@google.com>]

On 09/16/2016 03:55 PM, Junio C Hamano wrote:
> Hmph, these:
>
>  t/t5100/info0008--no-inbody-headers  | 5 +++++
>  t/t5100/msg0008--no-inbody-headers   | 6 ++++++
>  t/t5100/msg0015--no-inbody-headers   | 1 +
>
> have --no-inbody-headers in their names; wouldn't that an indication
> that they are expected output when mailinfo is run while in-body
> header feature disabled?

Yes, that's correct (they are the test data for when the in-body header 
feature is disabled).

> I would have expected that it would make more sense to make no
> change to sample.mbox and have updated expectation to outputs in the
> case where in-body header feature is enabled.

The sample.mbox file contains the following:

   From nobody Mon Sep 17 00:00:00 2001
   From: A U Thor <a.u.thor@example.com>
   Subject: check bogus body header (from)
   Date: Fri, 9 Jun 2006 00:44:16 -0700

   From: bogosity
     - a list
     - of stuff

Unchanged, the subsequent patch would break this test because it would 
interpret that as a multi-line "From" in-body header when in-body 
headers are *not* disabled.

Besides changing sample.mbox, the other way to make sure that this test 
passes is to suppress the test when in-body headers are *not* disabled, 
but looking at t5100* (directory and script), it seemed more 
straightforward to modify sample.mbox.

The patch I sent added a blank line after "From: bogosity", but removing 
the spaces before "- a list" and "- of stuff" would work too.

> To make sure this new feature will not break in the future, we would
> want a brand new message with a folded in-body header added to the
> sample.mbox, and see how it is parsed by mailinfo with in-body
> header feature enabled (and disabled).

OK, I'll add this test. (The subsequent patch already has the brand new 
message, but not the test where in-body headers are disabled.)