public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
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

  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