On Mon, Apr 01, 2013 at 02:21:22AM +0530, Ramkumar Ramachandra wrote: > Jeff King wrote: > > [...] > > So, you're saying: don't test compound statements for failure, since > anything in the chain could fail and propagate failure. I should only > test simple git-foo commands for failure? Right. > > Sometimes it's annoyingly verbose to break down a compound function. But > > I think in this case, you can make your tests more robust by just > > checking the affirmative that the ref is still where we expect it to be, > > like: > > > > check_push_result up_repo $the_first_commit heads/master > > Doesn't that change the meaning of the test though? I really like how > the original tests read. Does it? I thought the original was: test_must_fail check_push_result up_repo $the_commit heads/master which is checking that we did _not_ push $the_commit to up_repo. Checking that without a negative means confirming that what _used_ to be there is still there, which is $the_first_commit. But I didn't actually run it, so I might be wrong about what is supposed to be there after the (lack of) push. -Peff -- 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