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
>>> 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...
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html