Re: Git Test Coverage Report (Feb. 18, 2020)

[Derrick Stolee <stolee@gmail.com>]

Here are some notes that apply to the changed-path Bloom filter series [1].

[1] https://lore.kernel.org/git/pull.497.v2.git.1580943390.gitgitgadget@gmail.com/

On 2/18/2020 7:46 AM, Derrick Stolee wrote:
> Derrick Stolee	92667ee9 commit-graph: examine commits by generation number
> commit-graph.c
> 92667ee9 89) else if (a->date > b->date)
> 92667ee9 90) return 1;
> 92667ee9 91) return 0;
> 92667ee9 1296) QSORT(sorted_by_pos, ctx->commits.nr, commit_pos_cmp);

This QSORT not being covered means we are not testing the --changed-paths
option with an input option that scans pack-files, and instead always using
--reachable.

Garima: could we update Peff's commit that originally introduced this QSORT
to have such a test? Thanks!

> Garima Singh	282c08a9 commit-graph: write Bloom filters to commit graph file
> commit-graph.c
> 282c08a9 328) chunk_repeated = 1;
> 282c08a9 335) chunk_repeated = 1;
> 282c08a9 342) break;
> 282c08a9 371) graph->chunk_bloom_indexes = NULL;
> 282c08a9 372) graph->chunk_bloom_data = NULL;
> 282c08a9 373) graph->bloom_filter_settings = NULL;

I wouldn't worry about testing these error conditions.

> 282c08a9 1087) progress = start_delayed_progress(
> 282c08a9 1089) ctx->commits.nr);
> 282c08a9 1112) progress = start_delayed_progress(
> 282c08a9 1114) ctx->commits.nr);
> 282c08a9 1288) progress = start_delayed_progress(

But, could we have a test that verifies the progress is output for these
steps? Use GIT_PROGRESS_DELAY=0 to guarantee that the strings are output.

> Garima Singh	b6d925e7 bloom: core Bloom filter implementation for changed paths
> bloom.c
> b6d925e7 247) for (i = 0; i < diff_queued_diff.nr; i++)
> b6d925e7 248) diff_free_filepair(diff_queued_diff.queue[i]);
> b6d925e7 249) filter->data = NULL;
> b6d925e7 250) filter->len = 0;

These are a result of the case of a commit having over 512 changes. I think
there is a follow-up item to make this 512 value be configurable, and when
we do that, then we should add a test that covers this case, but with a
smaller configured value.

> t/helper/test-bloom.c
> b6d925e7 20) printf("No filter.\n");
> b6d925e7 21) return;

This could be covered similarly with such a test.
 
> Jeff King	dc9f0216 commit-graph: examine changed-path objects in pack order
> commit-graph.c
> dc9f0216 62) return; /* should never happen, but be lenient */
> dc9f0216 67) static int commit_pos_cmp(const void *va, const void *vb)
> dc9f0216 69) const struct commit *a = *(const struct commit **)va;
> dc9f0216 70) const struct commit *b = *(const struct commit **)vb;
> dc9f0216 71) return commit_pos_at(&commit_pos, a) -
> dc9f0216 72)        commit_pos_at(&commit_pos, b);

As mentioned earlier, we just don't cover --changed-paths along with
scanning pack-files, but we should.

Thanks,
-Stolee