Re: [GSoC PATCH v5 2/5] repo: add the field references.format

From: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
Date: Jul 23, 2025, 18:26 UTC
Message-ID: <B2B2D8E4-DD78-4ACB-921D-A8747A0AB0CF@gmail.com>
In-Reply-To: <ldomqfgzts2fs3zuzuyfpsp4jsuec7a6ooisztqx6pe2373jzx@mqzh62weo2jm>

Show 5 quoted lines

> Ok, so each key has a corresponding callback that is used to get its
> value. This works fine when we have one operation/callback per key, but
> I could see this being a bit inflexible in cases where performing a
> single operation could be expected to generate multiple keys worth of
> information at a time.

For git-repo-info it wouldn't be a problem, as we return one value per requested key.

However, I plan to add a feature in the future for requesting a group of fields. For example:

$ git repo info layout layout.bare=true layout.shallow=false

which, of course, is not what exactly you mean :-). But it is a similar problem of requesting one key and getting several key-value pairs.

> I certainly see this being the case with git-repo-stats where, for
> example, interating over references will produce multiple keyvalues
> indicating the number of branches, tags, remotes, etc. But, maybe for
> git-repo-info this will not be as much of a concern?

For git-repo-info it isn't, at least by the planned set of values. However, given that I have plans to add the previous feature, I can try to make it flexible for doing things like:

$ git repo stats object.count object.count.blob=123 object.count.tree=456 object.count.commit=789

So you can use the same code for outputting git-repo-stats data. By now, I plan to finish the basic functionality (i.e. finishing this "skeleton" and adding the rest of the proposed fields), then I'll think about this feature.

I think the current solution is simple enough to being refactored to support this kind of thing in the future.

> If the user does not input any keys, we simply do nothing. I do wonder
> if this is really the best default behavior.

In previous versions it returned all the available fields. There was a `--allow-empty` flag that allowed to request no field.

After the discussion in [1] we agreed that it would be better to return nothing by default and add a `--all` flag for returning all the fields (or a default set of fields).