Re: Git Test Coverage Report (v2.29.0-rc0)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/6/2020 4:38 PM, Derrick Stolee wrote:
> brian m. carlson	d7e6b6a8 fast-import: convert internal structs to struct object_id
> brian m. carlson	912c13d5 fast-import: convert to struct object_id
> brian m. carlson	e6a492b7 pack: convert struct pack_idx_entry to struct object_id
> brian m. carlson	28d055bd fast-import: make hash-size independent

These are clear refactors that should not be considered against the
author.

> Derrick Stolee	4ddc79b2 maintenance: add auto condition for commit-graph task

Here, it seems I missed testing "git maintenance run --auto --task=commit-graph".
I will send a patch to correct this sometime this week.

> Han-Wen Nienhuys	4441f427 refs: add GIT_TRACE_REFS debugging mechanism
> refs/debug.c

This file seems rather non-trivial to not be covered. However, if GIT_TRACE_REFS
is only intended for debugging, then perhaps none of this is in a critical code
path that would affect normal users?

> Jeff King	c33ddc2e date: use strbufs in date-formatting functions> Jeff King	d70a9eb6 strvec: rename struct fields
> Jeff King	ef8d7ac4 strvec: convert more callers away from argv_array name
> Jeff King	c972bf4c strvec: convert remaining callers away from argv_array name

This is another giant refactor.

> Jonathan Tan	f08cbf60 index-pack: make quantum of work smaller
> builtin/index-pack.c
> f08cbf60 424) list_for_each_prev(pos, &done_head) {
> f08cbf60 425) struct base_data *b = list_entry(pos, struct base_data, list);
> f08cbf60 426) if (b->retain_data || b == retain)
> f08cbf60 427) continue;
> f08cbf60 428) if (b->data) {
> f08cbf60 429) free_base_data(b);
> f08cbf60 430) if (base_cache_used <= base_cache_limit)
> f08cbf60 431) return;
> f08cbf60 435) list_for_each_prev(pos, &work_head) {
> f08cbf60 436) struct base_data *b = list_entry(pos, struct base_data, list);
> f08cbf60 437) if (b->retain_data || b == retain)
> f08cbf60 438) continue;
> f08cbf60 439) if (b->data) {
> f08cbf60 440) free_base_data(b);
> f08cbf60 441) if (base_cache_used <= base_cache_limit)
> f08cbf60 442) return;
> f08cbf60 925) base_cache_used += c->size;
> f08cbf60 941) base_cache_used += c->size;

This seems to be sufficiently complicated to be worth a test.
What do you think, Jonathan?
 
These are the items that caught my eye.

Thanks,
-Stolee




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux