Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Actually, I find it much harder to debug these "the output must match > these precise bytes, else we fail" type of test cases. Instead, I describe > in a natural way what is expected: > > ! has_cr actual > > Now, when the test fails, whoever is that poor soul tasked with debugging > and fixing the breakage knows *what* goes wrong, conceptually.
I am of two minds but 60% in favor of the "We only care about presense of CR" approach. Of course, the remaining 40% is "other people may break the code in such a way that still has CR at the end of the line but change ealier bytes on the line in the future (an obvious way to do so is to turn an input "ABC\n" into "AB\r\n"), and we would want to catch it". But the conversion machinery is tested elsewhere in the test suite, and this test is more about the cat-file command making a call into the conversion machinery when and only when it is necessary, so that sways me towards "has_cr is what we want here". > Could you please start surrounding your replies by empty lines? Good suggestion. I have exactly the same problem whenever I read messages without blanks at paragraph boundaries. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
