All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mark C. Chu-Carroll" <markchucarroll@fastmail.com>
To: "Patrick Steinhardt" <ps@pks.im>,
	"Mark C. Chu-Carroll" <markchucarroll@fastmail.com>
Cc: <git@vger.kernel.org>, <jltobler@gmail.com>
Subject: Re: [PATCH 1/1] repo: add filtering options to "repo structure"
Date: Mon, 05 Oct 2026 14:52:27 -0400	[thread overview]
Message-ID: <DLX4QVXQJTQ4.24JR7ES0P3H@fastmail.com> (raw)
In-Reply-To: <ar04uStCZ4pnEJ38@pks.im>

On Wed Sep 30, 2026 at 12:28 PM EDT, Patrick Steinhardt wrote:
> On Thu, Sep 24, 2026 at 12:45:03PM -0400, Mark C. Chu-Carroll wrote:
>> "git repo structure" provides a collection of useful information
>> about the information stored in a repo. In particular, it's
>> valuable for diagnosing performance issues caused by large objects
>> stored in a repo.
>> 
>> The current implementation of "git repo stucture" provides summary
>> information about everything in the repository - all of the
>> branches, remotes, tags, stashes, and notes. But sometimes
>> to properly diagnose a problem, it's useful to be able to exclude
>> refs that are known to not be relevant to the issue at hand.
>
> Yes, indeed. Sometimes you may for example want to figure out where
> exactly the storage size of a particular repository is going. Or in the
> case of GitLab for example, we may have bookkeeping references that are
> not controllable by customers. So we may only want to get the structure
> for all the customer-controllable branches there.
>
>> Add a set of flags that allow a user to selective exclude
>> reference types from the report generated by "git repo structure".
>> When a ref type is excluded by the filter, it no longer appears
>> in the report (ie, if "--no-tags" is passed, the report line
>> for "Branches" will no longer appear under "* References").
>> Following the pattern of flags that are only used to
>> disable functionality (eg, "--no-verify" in "builtins/push.c"),
>> only the "--no-<reftype>" syntax is listed in the updated
>> documentation.
>
> Hmm, okay. I would have expected that the user can essentially pass
> arbitrary revisions as understood by git-log(1) et al. And if they pass
> any such revisions, we should not enumerate anything but what they have
> passed, so the flags shouldn't only be used to exclude.
>
> So, for example:
>
>     $ git repo structure --branches
>     $ git repo structure master
>     $ git repo structure --all --not --branches
>
> I would hope that git-repo(1) can achieve that rather easily because I
> expect that it uses `struct rev_info`, but let's read on.

That makes sense. My initial understanding was that most of what 
"git repo structure" does is internalize the functionality of git-sizer
into the core of git. The only filters offered by git-sizer are 
type-based. But I agree that a commit list based filter is a lot 
more useful, so I've updated the patch set to implement it.

   -Mark



-- 
Mark Craig Chu-Carroll (@MarkChuCarroll at gitlab)
*** Software Tools/Math Geek - Software Engineer at Gitlab
*** Work Email: mcarroll@gitlab.com / markchucarroll@fastmail.com
*** Personal Blog: http://goodmath.org/blog / Personal email: markcc@gmail.com


  reply	other threads:[~2026-10-05 18:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 16:45 [PATCH 0/1] repo: add filtering options to "repo structure" Mark C. Chu-Carroll
2026-09-24 16:45 ` [PATCH 1/1] " Mark C. Chu-Carroll
2026-09-30 16:28   ` Patrick Steinhardt
2026-10-05 18:52     ` Mark C. Chu-Carroll [this message]
2026-10-05 17:40   ` [PATCH v2 0/1] " Mark C. Chu-Carroll
2026-10-05 17:40     ` [PATCH v2 1/1] " Mark C. Chu-Carroll
2026-10-06  5:51       ` Patrick Steinhardt
2026-10-08 15:46         ` Kaartic Sivaraam
2026-10-09 15:49           ` Mark C. Chu-Carroll
2026-10-09 18:09   ` [PATCH v3 0/1] repo: add revision " Mark C. Chu-Carroll
2026-10-09 18:09     ` [PATCH v3 1/1] repo: add " Mark C. Chu-Carroll
2026-10-09 21:24       ` Junio C Hamano
2026-10-10 14:31         ` Mark C. Chu-Carroll
2026-10-10 15:05   ` [PATCH v4 0/1] repo: add revision " Mark C. Chu-Carroll
2026-10-10 15:05     ` [PATCH v4 1/1] repo: add " Mark C. Chu-Carroll
2026-10-13 11:50       ` Patrick Steinhardt
2026-10-13 13:56         ` Mark C. Chu-Carroll
2026-10-13 14:05           ` Patrick Steinhardt
2026-10-13 17:28     ` [PATCH v5 0/1] repo: add revision " Mark C. Chu-Carroll
2026-10-13 17:28       ` [PATCH v5 1/1] repo: add " Mark C. Chu-Carroll

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=DLX4QVXQJTQ4.24JR7ES0P3H@fastmail.com \
    --to=markchucarroll@fastmail.com \
    --cc=git@vger.kernel.org \
    --cc=jltobler@gmail.com \
    --cc=ps@pks.im \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.