Re: [PATCH v8 1/5] Introduce bulk-move detection in diffcore.

From: Yann Dirson <ydirson@free.fr>
Date: Nov 4, 2010, 21:56 UTC
Message-ID: <20101104215625.GB3167@home.lan>
In-Reply-To: <20101030002600.GC21410@burratino>

On Fri, Oct 29, 2010 at 07:26:00PM -0500, Jonathan Nieder wrote:

Show 12 quoted lines

> 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.

Show 7 quoted lines

> >> 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