Re: Git Test Coverage Report (March 31, 2020)

From: Derrick Stolee <stolee@gmail.com>
Date: Apr 1, 2020, 13:27 UTC
Message-ID: <064fe1c7-3c93-fd82-ad78-92f800713462@gmail.com>
In-Reply-To: <20200401095635.GB60227@coredump.intra.peff.net>

On 4/1/2020 5:56 AM, Jeff King wrote:

Show 15 quoted lines

> On Tue, Mar 31, 2020 at 09:58:17PM -0400, Derrick Stolee wrote:
> 
>> Uncovered code in 'jch' not in 'next'
>> --------------------------------------------------------
>> [...]
>> Jeff King	16ddcd40 sha1_array: let callbacks interrupt iteration
>> oid-array.c
>> 16ddcd40 76) return ret;
> 
> Hmm, that commit is from 2016. I guess it was triggered now because I
> renamed sha1-array.c to oid-array.c recently. I'm not sure what the
> right thing is here. Following the movement via blames a long-ago commit
> (I just happen to be the author of both in this case). But not following
> the movement means that my rename would get blamed for code that isn't
> actually new.

Interesting. The test-coverage tool is checking blame after checking a diff, so the two are not as linked as they could be. The diff tries to find all modified lines in the files that were updated, and filters the blame output based on those. I suspect this will happen whenever we rename a file.

The "real" fix would be to filter out the blame lines for commits that don't actually fit in the commit range we are considering.

Thanks for looking closely!

-Stolee