From: Justin Tobler <jltobler@gmail.com>
Date: Wed, 18 Feb 2026 20:13:26 GMT
Subject: Re: [PATCH 3/5] builtin/repo: add OID annotations to table output
Message-ID: <aZYb9BBBjlviZsnR@denethor>
In-Reply-To: <aY8jt_8LoN1LdboG@pks.im>

On 26/02/13 02:14PM, Patrick Steinhardt wrote:
> 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.

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

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