Re: Git Test Coverage Report (Feb. 18, 2020)
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Feb 18, 2020, 12:55 UTC
- Message-ID
- <d3635fdf-1948-5d58-a1bf-abd5f56b18d1@gmail.com>
- In-Reply-To
- <2c97befe-9be8-9946-b643-91656fa3dcd8@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:
Show 6 quoted lines
> 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!
Show 8 quoted lines
> 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.
Show 5 quoted lines
> 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.
Show 6 quoted lines
> 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.
Show 8 quoted lines
> 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