From: Jonathan Tan Date: Sat, 17 Sep 2016 00:31:44 GMT Subject: Re: [RFC/PATCH 2/3] mailinfo: correct malformed test example Message-ID: <3a27685f-a53b-03a7-93d5-0492638faf51@google.com> In-Reply-To: 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 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.)