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.t...@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.)

Reply via email to