Re: [PATCH 3/5] builtin/repo: add OID annotations to table output
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Feb 13, 2026, 13:14 UTC
- Message-ID
- <aY8jt_8LoN1LdboG@pks.im>
- In-Reply-To
- <20260203221758.1164434-4-jltobler@gmail.com>
On Tue, Feb 03, 2026 at 04:17:56PM -0600, Justin Tobler wrote:
Show 13 quoted lines
> 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));
Show 9 quoted lines
> @@ -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.
Show 19 quoted lines
> @@ -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?
Show 84 quoted lines
> 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