From: Patrick Steinhardt <ps@pks.im>
To: Justin Tobler <jltobler@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/5] builtin/repo: add OID annotations to table output
Date: Fri, 13 Feb 2026 14:14:31 +0100 [thread overview]
Message-ID: <aY8jt_8LoN1LdboG@pks.im> (raw)
In-Reply-To: <20260203221758.1164434-4-jltobler@gmail.com>
On Tue, Feb 03, 2026 at 04:17:56PM -0600, Justin Tobler wrote:
> diff --git a/builtin/repo.c b/builtin/repo.c
> index 51a4359685..6fc2d9db12 100644
> --- a/builtin/repo.c
> +++ b/builtin/repo.c
> @@ -272,6 +275,12 @@ static void stats_table_vaddf(struct stats_table *table,
> table->name_col_width = name_width;
> if (!entry)
> return;
> + if (entry->oid) {
> + entry->index = table->annotations.nr + 1;
> + strbuf_addf(&buf, "[%" PRIuMAX "] %s", (uintmax_t)entry->index,
> + oid_to_hex(entry->oid));
> + string_list_append(&table->annotations, buf.buf);
Can't we hand over ownership here to avoid the extra string copy?
string_list_append_nodup(&table->rows, strbuf_detach(&buf, NULL));
> @@ -282,6 +291,8 @@ static void stats_table_vaddf(struct stats_table *table,
> if (unit_width > table->unit_col_width)
> table->unit_col_width = unit_width;
> }
> +
> + strbuf_release(&buf);
> }
>
> static void stats_table_addf(struct stats_table *table, const char *format, ...)
I was wondering why we only start releasing the buffer now. But before
these changes we used `strbuf_detach()` on it, so there's been no memory
leak here.
> @@ -321,6 +332,27 @@ static void stats_table_size_addf(struct stats_table *table, size_t value,
> va_end(ap);
> }
>
> +static void stats_table_object_size_addf(struct stats_table *table,
> + struct object_id *oid, size_t value,
> + const char *format, ...)
> +{
> + struct stats_table_entry *entry;
> + va_list ap;
> +
> + CALLOC_ARRAY(entry, 1);
> + humanise_bytes(value, &entry->value, &entry->unit, HUMANISE_COMPACT);
> +
> + /*
> + * A NULL OID should not have a table annotation.
> + */
> + if (!is_null_oid(oid))
> + entry->oid = oid;
I guess this case could be hit if a certain object type didn't have any
objects at all?
> diff --git a/t/t1901-repo-structure.sh b/t/t1901-repo-structure.sh
> index 1999f325d0..918af7269f 100755
> --- a/t/t1901-repo-structure.sh
> +++ b/t/t1901-repo-structure.sh
> @@ -89,41 +89,46 @@ test_expect_success SHA1 'repository with references and objects' '
> # git-rev-list(1) --disk-usage=human option printing the full
> # "byte/bytes" unit string instead of just "B".
> cat >expect <<-EOF &&
> - | Repository structure | Value |
> - | -------------------- | ---------- |
> - | * References | |
> - | * Count | 4 |
> - | * Branches | 1 |
> - | * Tags | 1 |
> - | * Remotes | 1 |
> - | * Others | 1 |
> - | | |
> - | * Reachable objects | |
> - | * Count | 3.02 k |
> - | * Commits | 1.01 k |
> - | * Trees | 1.01 k |
> - | * Blobs | 1.01 k |
> - | * Tags | 1 |
> - | * Inflated size | 16.03 MiB |
> - | * Commits | 217.92 KiB |
> - | * Trees | 15.81 MiB |
> - | * Blobs | 11.68 KiB |
> - | * Tags | 132 B |
> - | * Disk size | $(object_type_disk_usage all true) |
> - | * Commits | $(object_type_disk_usage commit true) |
> - | * Trees | $(object_type_disk_usage tree true) |
> - | * Blobs | $(object_type_disk_usage blob true) |
> - | * Tags | $(object_type_disk_usage tag) B |
> - | | |
> - | * Largest objects | |
> - | * Commits | |
> - | * Maximum size | 223 B |
> - | * Trees | |
> - | * Maximum size | 32.29 KiB |
> - | * Blobs | |
> - | * Maximum size | 13 B |
> - | * Tags | |
> - | * Maximum size | 132 B |
> + | Repository structure | Value |
> + | ------------------------ | ---------- |
> + | * References | |
> + | * Count | 4 |
> + | * Branches | 1 |
> + | * Tags | 1 |
> + | * Remotes | 1 |
> + | * Others | 1 |
> + | | |
> + | * Reachable objects | |
> + | * Count | 3.02 k |
> + | * Commits | 1.01 k |
> + | * Trees | 1.01 k |
> + | * Blobs | 1.01 k |
> + | * Tags | 1 |
> + | * Inflated size | 16.03 MiB |
> + | * Commits | 217.92 KiB |
> + | * Trees | 15.81 MiB |
> + | * Blobs | 11.68 KiB |
> + | * Tags | 132 B |
> + | * Disk size | $(object_type_disk_usage all true) |
> + | * Commits | $(object_type_disk_usage commit true) |
> + | * Trees | $(object_type_disk_usage tree true) |
> + | * Blobs | $(object_type_disk_usage blob true) |
> + | * Tags | $(object_type_disk_usage tag) B |
> + | | |
> + | * Largest objects | |
> + | * Commits | |
> + | * Maximum size [1] | 223 B |
> + | * Trees | |
> + | * Maximum size [2] | 32.29 KiB |
> + | * Blobs | |
> + | * Maximum size [3] | 13 B |
> + | * Tags | |
> + | * Maximum size [4] | 132 B |
> +
> + [1] 0dc91eb18580102a3a216c8bfecedeba2b9f9b9a
> + [2] 60665251ab71dbd8c18d9bf2174f4ee0d58aa06c
> + [3] 97d808e45116bf02103490294d3d46dad7a2ac62
> + [4] 4dae4f5954f5e6feb3577cfb1b181daa3fd3afd2
> EOF
I was briefly wondering whether we can do better here and for example
output something like this:
| * Largest objects | |
| * Commits | |
| * Maximum size [commits] | 223 B |
[commits] 0dc91eb18580102a3a216c8bfecedeba2b9f9b9a
But I think that becomes quite unwieldy as the column's size is extended
quite a bit, so numbers it probably the better interface.
Patrick
next prev parent reply other threads:[~2026-02-13 13:14 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 22:17 [PATCH 0/5] builtin/repo: include largest object information Justin Tobler
2026-02-03 22:17 ` [PATCH 1/5] builtin/repo: update stats for each object Justin Tobler
2026-02-03 22:36 ` Junio C Hamano
2026-02-18 19:40 ` Justin Tobler
2026-02-26 19:20 ` Junio C Hamano
2026-02-26 19:29 ` Justin Tobler
2026-02-03 22:17 ` [PATCH 2/5] builtin/repo: collect largest inflated objects Justin Tobler
2026-02-03 22:45 ` Junio C Hamano
2026-02-18 20:01 ` Justin Tobler
2026-02-03 22:17 ` [PATCH 3/5] builtin/repo: add OID annotations to table output Justin Tobler
2026-02-13 13:14 ` Patrick Steinhardt [this message]
2026-02-18 20:13 ` Justin Tobler
2026-02-03 22:17 ` [PATCH 4/5] builtin/repo: find commit with most parents Justin Tobler
2026-02-03 22:48 ` Junio C Hamano
2026-02-03 23:14 ` Kristoffer Haugsbakk
2026-02-03 23:33 ` Junio C Hamano
2026-02-18 20:06 ` Justin Tobler
2026-02-03 22:17 ` [PATCH 5/5] builtin/repo: find tree with most entries Justin Tobler
2026-02-03 22:50 ` Junio C Hamano
2026-02-04 8:28 ` Patrick Steinhardt
2026-02-04 15:28 ` Junio C Hamano
2026-02-23 17:41 ` [PATCH v2 0/5] builtin/repo: include largest object information Justin Tobler
2026-02-23 17:41 ` [PATCH v2 1/5] builtin/repo: update stats for each object Justin Tobler
2026-02-23 17:41 ` [PATCH v2 2/5] builtin/repo: collect largest inflated objects Justin Tobler
2026-02-26 19:50 ` Junio C Hamano
2026-03-02 17:28 ` Justin Tobler
2026-02-28 23:36 ` Lucas Seiki Oshiro
2026-03-02 17:38 ` Justin Tobler
2026-02-23 17:41 ` [PATCH v2 3/5] builtin/repo: add OID annotations to table output Justin Tobler
2026-02-26 19:56 ` Junio C Hamano
2026-03-02 17:39 ` Justin Tobler
2026-02-23 17:41 ` [PATCH v2 4/5] builtin/repo: find commit with most parents Justin Tobler
2026-02-23 17:41 ` [PATCH v2 5/5] builtin/repo: find tree with most entries Justin Tobler
2026-02-24 9:35 ` [PATCH v2 0/5] builtin/repo: include largest object information Patrick Steinhardt
2026-02-28 23:43 ` Lucas Seiki Oshiro
2026-03-01 19:22 ` Justin Tobler
2026-03-02 21:45 ` [PATCH v3 0/6] " Justin Tobler
2026-03-02 21:45 ` [PATCH v3 1/6] builtin/repo: update stats for each object Justin Tobler
2026-03-02 21:45 ` [PATCH v3 2/6] builtin/repo: add helper for printing keyvalue output Justin Tobler
2026-03-03 13:27 ` Patrick Steinhardt
2026-03-03 17:40 ` Junio C Hamano
2026-03-03 18:08 ` Justin Tobler
2026-03-02 21:45 ` [PATCH v3 3/6] builtin/repo: collect largest inflated objects Justin Tobler
2026-03-03 13:27 ` Patrick Steinhardt
2026-03-02 21:45 ` [PATCH v3 4/6] builtin/repo: add OID annotations to table output Justin Tobler
2026-03-02 21:45 ` [PATCH v3 5/6] builtin/repo: find commit with most parents Justin Tobler
2026-03-02 21:45 ` [PATCH v3 6/6] builtin/repo: find tree with most entries Justin Tobler
2026-03-02 22:09 ` [PATCH v3 0/6] builtin/repo: include largest object information Junio C Hamano
2026-03-06 22:36 ` Junio C Hamano
2026-03-08 18:44 ` Justin Tobler
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aY8jt_8LoN1LdboG@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox