Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> >> author Bugs Bunny 1234567890 +0000 >> committer Bugs Bunny <bugs@xxxxxx> 1234567890 +0000 > > This is covered by the "missingEmail" part of the test, but there's > nothing wrong with the timestamp itself. I think you didn't get what I meant. What makes you think "1234567890 +0000" on the first line is a timestamp in the first place? The parser could be updated and split that malformed string (as it lacks <...> thing we expect, which is what missing Email is about) differently from what you are expecting, causing the line to be broken in two ways, i.e. missing email and badly formatted timestamp. But we know for certain that the line is wrong not to have email in either parser (the current one, or a possibly updated one). So it is defensive to doubt your preconception that there is nothing wrong with the timestamp, and demote possible timestamp errors to warning, as that is not what we are interested in here. > I still think it makes sense to remove this particular thing. Let's add > exhaustive tests for all this fsck.* stuff in another series, but no > point in testing for arbitrary fsck errors that aren't going to be > triggered in unrelated tests. That is exactly what I am saying with "being defensive". Your change starts testing for arbitrary errors that are not relevant.
