list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <>
To: Git List <>,
	"brian m. carlson" <>,
	Han-Wen Nienhuys <>,
	Jonathan Tan <>,
	Jeff King <>
Subject: Re: Git Test Coverage Report (v2.29.0-rc0)
Date: Tue, 6 Oct 2020 16:49:45 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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


      reply	other threads:[~2020-10-06 20:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-06 20:38 Derrick Stolee
2020-10-06 20:49 ` Derrick Stolee [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).