Re: [PATCH 3/5] builtin/repo: add OID annotations to table output
- From
Justin Tobler <jltobler@gmail.com>
- Date
- Feb 18, 2026, 20:13 UTC
- Message-ID
- <aZYb9BBBjlviZsnR@denethor>
- In-Reply-To
- <aY8jt_8LoN1LdboG@pks.im>
On 26/02/13 02:14PM, Patrick Steinhardt wrote:
Show 18 quoted lines
> 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));Good suggestion. Will adapt in the next version.
Show 22 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?Yup. An example here would be running this command on an empty repository.
Show 96 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.
In later commits we also add more annotations. One example is max commit size and max commit parents may be diffent commit OIDs. I think numbers may be the simplest for now.
Thanks, -Justin