<p>The idea behind sending the test first is that people can see that it fails and that the subsequent patch indeed fixes it.  What I find works well is to submit the test case with the test marked as broken and then the main patch, including the change to un-mark it as broken.</p>

<div class="gmail_quote">On Sep 9, 2011 5:45 AM, "Thomas Schwinge" <<a href="mailto:thomas@schwinge.name">thomas@schwinge.name</a>> wrote:<br type="attribution">> Hi!<br>> <br>> On Fri, 9 Sep 2011 11:06:34 +0200, Louis Rilling <<a href="mailto:l.rilling@av7.net">l.rilling@av7.net</a>> wrote:<br>
>> On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote:<br>>> > Also, we generally prefer to have modifications to the test suite in<br>>> > separate patches that precede the patches that add the features/fix the<br>
>> > bugs.<br>>> > <br>>> <br>>> For new features, this does not look like 'git bisect'-safe.<br>> <br>> Exactly my thoughts.  I can perhaps see the usefulness (for first<br>> separately committing the testcase) for bugfixes, but why for new<br>
> features?<br>> <br>>> I would say that<br>>> the testsuite patch should follow the new feature patch, don't you?<br>> <br>> I would keep them together; why separate them?<br>> <br>> <br>
> Grüße,<br>>  Thomas<br></div>