Torsten Bögershausen schrieb am 22.11.2014 um 15:59: >>> +test_expect_success 'error out when attempting to add ignored ones but add others' ' >>> + touch a.if && >>> + test_must_fail git add a.?? && >>> + ! (git ls-files | grep "\\.ig") && >>> + (git ls-files | grep a.if) >>> +' >> >> I am somewhat allergic to pipes in our test suite, because they can mask >> errors (especially with a negated grep, because we do not know if they >> correctly produced any output at all). But I guess this is matching the >> surrounding code, and it is quite unlikely for `ls-files` to fail in any >> meaningful way here. So I think it's fine. >> >> -Peff > > 2 small comments: > Why the escaped "\\.ig" and the unescaped "a.if" ? Well, the first one is copied straight from another test and the second one is by me. ;) I want to test that no files ending in .ig are added, but that one file a.if is added. Knowing how the test is structured, it is higly unlikely that other people will add a file where the dot in a.if matches something other than a dot, but in the case of .ig I wouldn't be so sure. We could take the extra safety measure and quote "a\\.if" also, but to me that seems to make the test less readable. > The other question, this is a more general one, strikes me every time I see > ! grep > > Should we avoid it by writing "test_must_fail" instead of "!" ? > (The current code base has a mixture of both) > > The following came into my mind when working on another grepy thing, > and it may be unnecessary clumsy: > > test_expect_success 'error out when attempting to add ignored ones but add others' ' > touch a.if && > test_must_fail git add a.?? && > git ls-files >files.txt && > test_must_fail grep a.ig files.txt >/dev/null && > grep a.if files.txt >/dev/null && > rm files.txt > ' > > (It feels as if there should be a "grepnot" ;-) > I guess that was clarified in the ongoing discussion. > The 3rd comment: > Thanks for taking this up! Just scratching my own itches mostly these days :) Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html