On Fri, Oct 29, 2010 at 07:26:00PM -0500, Jonathan Nieder wrote: > Yann Dirson wrote: > > > Hm, I fear too much granularity would become meaningless :) > [...] > > If the code needs to be easier to understand, I'd > > rather add some more doc, than added commits that are basically > > "useless for bisect". > > Yes, the example list was probably a little overboard. Even so, the > idea was to maintain bisectability by introducing a few tests at a > time. That way, the fallout of a subfeature can easily be found with > "git bisect", among other benefits[1]. I like the idea when successive commits get new functionality, but we have to avoid introducing known-broken functionality and fixing them in later patches - and I fear the list as you described it was going that latter way. > >> Is the debugging output infrequent enough to just use a function > >> unconditionally? > > > > You mean, keep funccalls even with DEBUG_BULKMOVE is not set ? No, > > there are too many traces for that. > > Yep, that's what I meant. Alas. Well, thinking twice, calls to empty function would be optimized out, so yes, we don't need cpp magic at all. -- Yann -- 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