Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 786E7431FD0 for ; Fri, 9 Sep 2011 09:13:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id proMFs+P+k-T for ; Fri, 9 Sep 2011 09:13:10 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id D1A6B431FB6 for ; Fri, 9 Sep 2011 09:13:09 -0700 (PDT) Received: by qyk7 with SMTP id 7so269080qyk.5 for ; Fri, 09 Sep 2011 09:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eHj+kS7hK8Tm2eBZBOwSJ/X9b2X4o6iEZpuhqA4mrgs=; b=Od8BcF+n98/U0S71Ubv3xrr94b/nsp2j52o42cFDCqhBAozF3yqkJTa05NqUHt1QJD lRZbfm5OxEShJEX/TUbC8SKTV1eWnVJ5IkEaJvo63LF/lX+yvc2k6g2S6Xz0XGZ30NT5 +Bo+c8YKa9t3QrHzufHgdeqTbBPMTsATywwrs= MIME-Version: 1.0 Received: by 10.229.43.143 with SMTP id w15mr409448qce.140.1315584787098; Fri, 09 Sep 2011 09:13:07 -0700 (PDT) Sender: amdragon@gmail.com Received: by 10.229.2.201 with HTTP; Fri, 9 Sep 2011 09:13:06 -0700 (PDT) Received: by 10.229.2.201 with HTTP; Fri, 9 Sep 2011 09:13:06 -0700 (PDT) In-Reply-To: <87fwk63v86.fsf@kepler.schwinge.homeip.net> References: <1315249637-20179-1-git-send-email-thomas@schwinge.name> <87liu2kcq6.fsf@servo.factory.finestructure.net> <20110909090633.GA3178@localdomain> <87fwk63v86.fsf@kepler.schwinge.homeip.net> Date: Fri, 9 Sep 2011 12:13:06 -0400 X-Google-Sender-Auth: 7NkvJYnrZjluXlvOjCxParK5miU Message-ID: Subject: Re: [PATCH] notmuch restore --accumulate From: Austin Clements To: Thomas Schwinge Content-Type: multipart/alternative; boundary=00148539240ae82be004ac847386 Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 16:13:10 -0000 --00148539240ae82be004ac847386 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 t= o submit the test case with the test marked as broken and then the main patch= , including the change to un-mark it as broken. On Sep 9, 2011 5:45 AM, "Thomas Schwinge" wrote: > Hi! > > On Fri, 9 Sep 2011 11:06:34 +0200, Louis Rilling wrote: >> On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote: >> > Also, we generally prefer to have modifications to the test suite in >> > separate patches that precede the patches that add the features/fix th= e >> > bugs. >> > >> >> For new features, this does not look like 'git bisect'-safe. > > Exactly my thoughts. I can perhaps see the usefulness (for first > separately committing the testcase) for bugfixes, but why for new > features? > >> I would say that >> the testsuite patch should follow the new feature patch, don't you? > > I would keep them together; why separate them? > > > Gr=FC=DFe, > Thomas --00148539240ae82be004ac847386 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The idea behind sending the test first is that people can see that it fa= ils and that the subsequent patch indeed fixes it.=A0 What I find works wel= l is to submit the test case with the test marked as broken and then the ma= in patch, including the change to un-mark it as broken.

On Sep 9, 2011 5:45 AM, "Thomas Schwinge&qu= ot; <thomas@schwinge.name>= ; wrote:
> Hi!
>
> On Fri, 9 Sep 20= 11 11:06:34 +0200, Louis Rilling <l= .rilling@av7.net> wrote:
>> On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote:
>> = > Also, we generally prefer to have modifications to the test suite in>> > separate patches that precede the patches that add the feat= ures/fix the
>> > bugs.
>> >
>>
>> For new feat= ures, this does not look like 'git bisect'-safe.
>
> E= xactly my thoughts. I can perhaps see the usefulness (for first
> se= parately committing the testcase) for bugfixes, but why for new
> features?
>
>> I would say that
>> the testsu= ite patch should follow the new feature patch, don't you?
>
&= gt; I would keep them together; why separate them?
>
>
> Gr=FC=DFe,
> Thomas
--00148539240ae82be004ac847386--