On Friday 2015-03-13 16:06 -0700, Gregory Szorc wrote: > On Fri, Mar 13, 2015 at 3:49 PM, L. David Baron <dba...@dbaron.org> wrote: > > > On Friday 2015-03-13 15:34 -0700, Gregory Szorc wrote: > > > 1. Create a commit that introduces a new test > > > 2. Test it > > > 3. Create a commit that purportedly fixes the test > > > 4. Build > > > 5. Test and verify > > > 6. Fold the commits > > > > Sure, that's what I'd do in an ideal world. But in reality I > > sometimes start with 3 (especially if it's a bug that I notice by > > code inspection), at which point the obvious order to do the rest of > > the steps quickly and correctly is 1-2-4-5. (And I prefer not to do > > 6, actually, and to order the test as the earlier commit and then > > have the code patch actually remove the todo/fails annotation.) > > > > (I prefer to leave the commits separate as well - didn't want to add the > complication.) > > If you start with 3, why can't you reorder the commits? Is this a case of > "rebuilds take too long and I prefer the build system didn't add overhead?"
I do often reorder the commits, but I don't think that's related to the problem. The problem is just that I've modified both test and code (and done appropriate version control mechanics, whatever they are), and I'd like to try the test first before rebuilding the code. It is indeed a case where what I'm trying to optimize away is an extra rebuild. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
