On 2012.7.28 1:02 PM, Jonathan Nieder wrote: > Jonathan Nieder wrote: >> Michael G Schwern wrote: > >>> I would suggest that worrying whether a few lines of code are introduced now >>> or 10 patches later in the same branch which is all going to be merged in one >>> go (and retesting the patches after it) is not the most important thing. > [...] >> In that case they should be one patch, I'd think. >> >> The advantage of introducing changes gradually is that (1) the changes >> can be examined and tested one at a time, and (2) if later a change >> proves to be problematic, it can be isolated, understood, and fixed >> more easily. The strategy you are suggesting would have neither of >> those advantages. > > (To avoid confusion: by "The strategy you are suggesting" I mean > introducing dead code first and activating it later, not the path and > url object idea. The path and url object approach would be very > nice. :)) If this is all a topic branch then it doesn't matter much whether a couple lines of code is introduced at patch 8 of a branch or patch 13. Sure, it matters a little, but... https://secure.wikimedia.org/wikipedia/en/wiki/Opportunity_cost If it *isn't* going in a topic branch, if its not visible as a collected work in history, if its going to be rebased on top of master, then yeah I can see why you're so concerned. -- Alligator sandwich, and make it snappy! -- 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