Date: Fri, 9 Sep 2011 13:35:37 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: Thomas Schwinge <thomas@schwinge.name>
Subject: Re: [PATCH] notmuch restore --accumulate
Message-ID: <20110909173537.GU5688@mit.edu>
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>
	<CAH-f9WutmDs2=UELduO66YPPFhy1g8D4_xNhnEjOiWaJMv7m5Q@mail.gmail.com>
	<87fwk53a1i.fsf@kepler.schwinge.homeip.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87fwk53a1i.fsf@kepler.schwinge.homeip.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Thomas Schwinge on Sep 09 at  7:22 pm:
> Hi!
> 
> On Fri, 9 Sep 2011 12:13:06 -0400, Austin Clements <amdragon@mit.edu> wrote:
> > 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.
> 
> Ah, that's indeed a good approach for bug fixes (and it also preserves
> git bisect compatibility), but still: why separate patches for new
> functionality?  (I'm not trying to be a pain here, but would like to
> understand your rationale behind this.)

*shrugs* I don't think it's too important for new functionality,
though for review it's nice to be able to focus on just the
implementation or just the tests, rather than having the patches
intermingled.