> and additional git-path based locations.

This statement is too vague. Each one of the covered key-value pairs
needs to be mentioned and discussed about why they are being added.

> Extend git repo structure with deeper repository metrics inspired by
> git-sizer, including per-type maximum inflated and on-disk object sizes,
> maximum commit parent count, maximum tree entry count, longest/deepest
> blob path, and deepest annotated tag chain.

This patch is doing too much. It needs to be broken, at least, into 20
smaller patches, one per git-repo-info and git-repo-structure key.

> From: Eslam reda ragheb <eslam.reda.div@gmail.com>
> 
> Signed-off-by: Eslam reda ragheb <eslam.reda.div@gmail.com>

Missing patch message.

> test_expect_success 'mixed key/category requests preserve request order' '
> - cat >expect <<-\EOF &&
> - object.format=sha1
> + cat >expect <<-EOF &&
> + object.format=$(test_oid algo)

Don't send patches fixing the code you have just added. Instead, rewrite
the history applying the fix to the original patch.

On 26/02/22 06:28PM, eslam-reda-div via GitGitGadget wrote:
> From: eslam-reda-div <eslam.reda.div@gmail.com>
> 
> Improve git repo info by adding path-oriented keys that match values
> users currently obtain from git rev-parse, including common directory,
> git directory, top-level, superproject working tree, and additional
> git-path based locations.
> 
> Teach git repo info to accept category keys like layout and path,
> and add --path-format=(absolute|relative) so scripts can request the
> desired path style explicitly. The command now uses repository context
> passed to the command path instead of relying on global state.
> 
> Extend git repo structure with deeper repository metrics inspired by
> git-sizer, including per-type maximum inflated and on-disk object sizes,
> maximum commit parent count, maximum tree entry count, longest/deepest
> blob path, and deepest annotated tag chain.

Hello,

Just FYI, there is already a series on the list I'm currently working on
that is extending the "structure" output for git-repo [1] similar to
what is being done here. This series collects largest inflated object
info, max commit parents, and max tree entries. It does look like this
series is collecting a couple of other data points too, but maybe we
could do so it a separate followup series to the one I'm working on? :)

Thanks,
-Justin

[1]: https://lore.kernel.org/git/20260203221758.1164434-1-jltobler@gmail.com/

"Eslam reda ragheb via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Eslam reda ragheb <eslam.reda.div@gmail.com>
>
> Introduce an explicit repo_info context for the repo info codepath
> and thread it through value lookups and field printing.
>
> This removes direct coupling from these helpers to ad-hoc
> repository globals and makes key retrieval logic easier to extend
> safely.

The above makes it sound as if you are improving existing code where
existing helper functions are already making ad-hoc and unsafe
access to global variables, but I somehow doubt that is what is
happening here.

What does "these helpers" exactly refer to in this sentence?  The
ones you will introduce in patch 02/10?

    Currently helper functions of get_value_fn type receives the
    output buffer and repository instance as parameters, but we are
    about to teach "repo info" to retrieve information that requires
    to know more than just the repository (e.g., the prefix given
    when the command was invoked).  Introduce a new "repo_info"
    structure and update get_value_fn to take it as a parameter.

or something?

> Also teach git repo info to accept category names (for example,
> layout) and expand them to matching key.* entries in request
> order.

That smells like an unrelated change.  Wouldn't it better to do so
in a subsequent patch, so that each step will concentrate on doing
one thing and one thing well?

"Eslam reda ragheb via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Eslam reda ragheb <eslam.reda.div@gmail.com>
>
> Add a path category to git repo info with key-value pairs that
> mirror repository paths users commonly retrieve via rev-parse and
> git-path lookups.
> ...
> +static int get_path_git_prefix(struct repo_info *info, struct strbuf *buf)
> +{
> +	if (info->prefix)
> +		strbuf_addstr(buf, info->prefix);
> +	return 0;
> +}

Can (info->prefix && info->prefix[0] == '\0') be possible?  If so,
"repo info path.git-prefix" would not be able to help users who want
to know between (info->prefix == NULL) and info->prefix being an
empty string.

Hi Eslam

On 26/02/2026 21:14, Eslam reda ragheb via GitGitGadget wrote:
> From: Eslam reda ragheb <eslam.reda.div@gmail.com>
> > Add a path category to git repo info with key-value pairs that
> mirror repository paths users commonly retrieve via rev-parse and
> git-path lookups.

I think that makes sense, I'm not sure about some of the paths though, see below.

> This makes scripting against repo metadata more direct and avoids
> shelling out to multiple commands for related paths.

You can get more than one path at a time from "git rev-parse" so I'm not sure what this is saying.

It would be helpful to include the tests and Documentation for the new keys in this patch.

> The new keys are introduced as explicit path.* entries in
> repo_info_fields and are resolved through dedicated helpers.
> > This keeps lookup behavior predictable and makes future path
> additions straightforward.
> > Signed-off-by: Eslam reda ragheb <eslam.reda.div@gmail.com>
> ---

> @@ -74,6 +197,20 @@ static const struct field repo_info_fields[] = {
>   	{ "layout.bare", get_layout_bare },
>   	{ "layout.shallow", get_layout_shallow },
>   	{ "object.format", get_object_format },
> +	{ "path.common-dir", get_path_common_dir },
> +	{ "path.config-file", get_path_config_file },
> +	{ "path.git-dir", get_path_git_dir },
> +	{ "path.git-prefix", get_path_git_prefix },

I'm not sure about calling this 'git-prefix', 'prefix' might be more appropriate as it is about prefixing paths in the worktree rather than the git_dir.

> +	{ "path.grafts-file", get_path_grafts_file },
> +	{ "path.hooks-directory", get_path_hooks_directory },
> +	{ "path.index-file", get_path_index_file },
> +	{ "path.logs-directory", get_path_logs_directory },

We're moving away from file based refs and reflogs so I'm not sure adding this, pick-refs-file or refs-directory is a good idea as we should not be encouraging people to access these files directly.

> +	{ "path.objects-directory", get_path_objects_directory },
> +	{ "path.packed-refs-file", get_path_packed_refs_file },
> +	{ "path.refs-directory", get_path_refs_directory },
> +	{ "path.shallow-file", get_path_shallow_file },
> +	{ "path.superproject-working-tree", get_path_superproject_working_tree },
> +	{ "path.toplevel", get_path_toplevel },

'path.toplevel' matches the git-rev-parse option but 'path.work-tree' might be more descriptive?

What happens if 'path.toplevel' is requested in a bare repository?

Thanks

Phillip

>   	{ "references.format", get_references_format },
>   };
>   

Phillip Wood <phillip.wood123@gmail.com> writes:

>> +	{ "path.common-dir", get_path_common_dir },
>> +	{ "path.config-file", get_path_config_file },
>> +	{ "path.git-dir", get_path_git_dir },
>> +	{ "path.git-prefix", get_path_git_prefix },
>
> I'm not sure about calling this 'git-prefix', 'prefix' might be more 
> appropriate as it is about prefixing paths in the worktree rather than 
> the git_dir.

True.

>> +	{ "path.grafts-file", get_path_grafts_file },
>> +	{ "path.hooks-directory", get_path_hooks_directory },
>> +	{ "path.index-file", get_path_index_file },
>> +	{ "path.logs-directory", get_path_logs_directory },
>
> We're moving away from file based refs and reflogs so I'm not sure 
> adding this, pick-refs-file or refs-directory is a good idea as we 
> should not be encouraging people to access these files directly.
>
>> +	{ "path.objects-directory", get_path_objects_directory },
>> +	{ "path.packed-refs-file", get_path_packed_refs_file },
>> +	{ "path.refs-directory", get_path_refs_directory },

The same comment applies to these entries as well, as the pluggable
object database support is just beyond the horizon if I understand
correctly.

>> +	{ "path.shallow-file", get_path_shallow_file },
>> +	{ "path.superproject-working-tree", get_path_superproject_working_tree },
>> +	{ "path.toplevel", get_path_toplevel },
>
> 'path.toplevel' matches the git-rev-parse option but 'path.work-tree' 
> might be more descriptive?

I think the "git repo" thrust comes primarily from being unfamiliar
with "rev-parse" (and I wouldn't particularly encourage new people
to become familiar with it---it grew pretty much organically driven
by scripting needs without taking UI cleanliness into consideration
very much), so not many folks would find it disturbing that
"--toplevel" corresponds to "topOfTheWorkingTree".  Given that we
have a token to ask for superproject's working tree, giving a name
made after the same phrasing philosophy for the current project's
working tree would be a good thing, i.e., "path.working-tree".

> What happens if 'path.toplevel' is requested in a bare repository?

FWIW "git rev-parse --show-toplevel" dies with "must be run in a
work tree".  Better or worse, 

	rm -fr new
	git init new
	cd new/.git && git rev-parse --show-toplevel

also dies the same way, which I am not sure we want to inherit when
we are making a new interrogator command.

Thanks.

On 27/02/2026 19:51, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> >>> +	{ "path.objects-directory", get_path_objects_directory },
>>> +	{ "path.packed-refs-file", get_path_packed_refs_file },
>>> +	{ "path.refs-directory", get_path_refs_directory },
> > The same comment applies to these entries as well, as the pluggable
> object database support is just beyond the horizon if I understand
> correctly.

Good point. Also what is the "shallow file" below and should scripts be poking it directly?

>>> +	{ "path.shallow-file", get_path_shallow_file },
>>> +	{ "path.superproject-working-tree", get_path_superproject_working_tree },
>>> +	{ "path.toplevel", get_path_toplevel },
>>
>> 'path.toplevel' matches the git-rev-parse option but 'path.work-tree'
>> might be more descriptive?
> > I think the "git repo" thrust comes primarily from being unfamiliar
> with "rev-parse" (and I wouldn't particularly encourage new people
> to become familiar with it---it grew pretty much organically driven
> by scripting needs without taking UI cleanliness into consideration
> very much), so not many folks would find it disturbing that
> "--toplevel" corresponds to "topOfTheWorkingTree".  Given that we
> have a token to ask for superproject's working tree, giving a name
> made after the same phrasing philosophy for the current project's
> working tree would be a good thing, i.e., "path.working-tree".

That's a good idea

>> What happens if 'path.toplevel' is requested in a bare repository?
> > FWIW "git rev-parse --show-toplevel" dies with "must be run in a
> work tree".  Better or worse,
> > 	rm -fr new
> 	git init new
> 	cd new/.git && git rev-parse --show-toplevel
> > also dies the same way, which I am not sure we want to inherit when
> we are making a new interrogator command.

Yes, I think printing an empty value after the key would be better - I don't think there are any paths where we care about the distinction between NULL and ""

Thanks

Phillip

Phillip Wood <phillip.wood123@gmail.com> writes:

>> FWIW "git rev-parse --show-toplevel" dies with "must be run in a
>> work tree".  Better or worse,
>> 
>> 	rm -fr new
>> 	git init new
>> 	cd new/.git && git rev-parse --show-toplevel
>> 
>> also dies the same way, which I am not sure we want to inherit when
>> we are making a new interrogator command.
>
> Yes, I think printing an empty value after the key would be better - I 
> don't think there are any paths where we care about the distinction 
> between NULL and ""

If the new and safer variant of the command should signal "error" by
giving an empty string, it would work with its "--show-toplevel"
equivalent run in a bare repository.  In a working tree, it would
give a full/absolute path, and never be an empty string.  I am still
unsure what that new and safer one should do from inside the .git
directory.  "rev-parse --show-toplevel" dies.  $(cd .. && pwd) may
be another plausible and arguably more useful answer.

Your idea of equiating NULL and "", I do not think it would work
well with "git rev-parse --show-cdup" equivalent.  The command will
give us an empty string from the top-level of the working tree.

Curiously, in this sequence

	rm -fr new
	git init new
	cd new/.git && git rev-parse --show-cdup
	cd objects && git rev-parse --show-cdup

two "rev-parse" do not die with "must be run in a work tree", and
worse yet, they do not give you ".." or "../../", either.

It seems that one rule of "rev-parse --show-<some-path>" is that
"when you are inside .git directory of a non-bare repository, we'd
behave as if you are in a bare repository as if its working tree
does not exist", and the above is consistent with that rule.
"--show-cdup" does not fail but gives an empty string when run
anywhere in a bare repository.

But among "rev-parse --show-<anything>" that are about working tree
paths, there seems no unifying rule on what to do when in a bare
repsitory.  As we already saw, "--show-toplevel" dies without a
working tree.  This reflects the history of rev-parse that grew
organizally without a grand design.

If we are adding new and safer interface to these pieces of
information to "repo info", we may want to straighten these rules.

> Also teach git repo info to accept category names (for example,
> layout) and expand them to matching key.* entries in request
> order.

If you have a patch where its description says "Do A. Also do B"
when A and B are unrelated, there are good chances that it should
be splitted into two commits. This patch is an example of that.

Hi Eslam

On 27/02/2026 19:30, Eslam reda ragheb via GitGitGadget wrote:
> From: Eslam reda ragheb <eslam.reda.div@gmail.com>
> > Rename path.git-prefix to path.prefix, add path.work-tree as an alias
> for path.toplevel, and drop reflog/ref-file-oriented path keys.
> > This narrows the path surface to keys that are less tied to direct
> file access while keeping tests and documentation in sync.
> > Also normalize prefix handling in repo_info context so path.prefix has
> a stable empty-string behavior.

When you change a patch series based on a reviewer's feedback, you should use "git rebase -i" to edit or fixup the existing commits rather than adding new changes on top. That keeps the history cleaner as we don't need to know "I implemented it like this and than changed it to that". It also makes the patch series easier to review as reviewers don't waste their time commenting on changes in one patch that are then deleted in a later patch.

Thanks

Phillip

> Signed-off-by: Eslam reda ragheb <eslam.reda.div@gmail.com>
> ---
>   Documentation/git-repo.adoc | 14 ++++-------
>   builtin/repo.c              | 45 ++++++++--------------------------
>   t/t1900-repo.sh             | 48 +++++++++++++++++--------------------
>   3 files changed, 36 insertions(+), 71 deletions(-)
> > diff --git a/Documentation/git-repo.adoc b/Documentation/git-repo.adoc
> index b575977a4b..3d34c6edca 100644
> --- a/Documentation/git-repo.adoc
> +++ b/Documentation/git-repo.adoc
> @@ -114,7 +114,7 @@ Here's a list of the available keys and the values that they return:
>   `path.git-dir`::
>   	The path to the git directory.
>   > -`path.git-prefix`::
> +`path.prefix`::
>   	The path of the current working directory relative to the top-level
>   	directory.
>   > @@ -127,18 +127,9 @@ Here's a list of the available keys and the values that they return:
>   `path.index-file`::
>   	The path to the index file.
>   > -`path.logs-directory`::
> -	The path to the `logs` directory.
> -
>   `path.objects-directory`::
>   	The path to the objects directory.
>   > -`path.packed-refs-file`::
> -	The path to the `packed-refs` file.
> -
> -`path.refs-directory`::
> -	The path to the `refs` directory.
> -
>   `path.shallow-file`::
>   	The path to the `shallow` file.
>   > @@ -150,6 +141,9 @@ Here's a list of the available keys and the values that they return:
>   	The path to the top-level working tree directory, or an empty string
>   	for bare repositories.
>   > +`path.work-tree`::
> +	Alias for `path.toplevel`.
> +
>   `references.format`::
>   	The reference storage format. The valid values are:
>   +
> diff --git a/builtin/repo.c b/builtin/repo.c
> index ecd9d3aee5..9fbd13a358 100644
> --- a/builtin/repo.c
> +++ b/builtin/repo.c
> @@ -109,10 +109,9 @@ static int get_path_git_dir(struct repo_info *info, struct strbuf *buf)
>   	return 0;
>   }
>   > -static int get_path_git_prefix(struct repo_info *info, struct strbuf *buf)
> +static int get_path_prefix(struct repo_info *info, struct strbuf *buf)
>   {
> -	if (info->prefix)
> -		strbuf_addstr(buf, info->prefix);
> +	strbuf_addstr(buf, info->prefix);
>   	return 0;
>   }
>   > @@ -137,39 +136,12 @@ static int get_path_index_file(struct repo_info *info, struct strbuf *buf)
>   	return 0;
>   }
>   > -static int get_path_logs_directory(struct repo_info *info, struct strbuf *buf)
> -{
> -	struct strbuf path = STRBUF_INIT;
> -
> -	repo_info_add_path(info, buf, repo_git_path_replace(info->repo, &path, "logs"));
> -	strbuf_release(&path);
> -	return 0;
> -}
> -
>   static int get_path_objects_directory(struct repo_info *info, struct strbuf *buf)
>   {
>   	repo_info_add_path(info, buf, repo_get_object_directory(info->repo));
>   	return 0;
>   }
>   > -static int get_path_packed_refs_file(struct repo_info *info, struct strbuf *buf)
> -{
> -	struct strbuf path = STRBUF_INIT;
> -
> -	repo_info_add_path(info, buf, repo_git_path_replace(info->repo, &path, "packed-refs"));
> -	strbuf_release(&path);
> -	return 0;
> -}
> -
> -static int get_path_refs_directory(struct repo_info *info, struct strbuf *buf)
> -{
> -	struct strbuf path = STRBUF_INIT;
> -
> -	repo_info_add_path(info, buf, repo_git_path_replace(info->repo, &path, "refs"));
> -	strbuf_release(&path);
> -	return 0;
> -}
> -
>   static int get_path_shallow_file(struct repo_info *info, struct strbuf *buf)
>   {
>   	struct strbuf path = STRBUF_INIT;
> @@ -201,6 +173,11 @@ static int get_path_toplevel(struct repo_info *info, struct strbuf *buf)
>   	return 0;
>   }
>   > +static int get_path_work_tree(struct repo_info *info, struct strbuf *buf)
> +{
> +	return get_path_toplevel(info, buf);
> +}
> +
>   static int get_references_format(struct repo_info *info, struct strbuf *buf)
>   {
>   	struct repository *repo = info->repo;
> @@ -217,17 +194,15 @@ static const struct field repo_info_fields[] = {
>   	{ "path.common-dir", get_path_common_dir },
>   	{ "path.config-file", get_path_config_file },
>   	{ "path.git-dir", get_path_git_dir },
> -	{ "path.git-prefix", get_path_git_prefix },
>   	{ "path.grafts-file", get_path_grafts_file },
>   	{ "path.hooks-directory", get_path_hooks_directory },
>   	{ "path.index-file", get_path_index_file },
> -	{ "path.logs-directory", get_path_logs_directory },
>   	{ "path.objects-directory", get_path_objects_directory },
> -	{ "path.packed-refs-file", get_path_packed_refs_file },
> -	{ "path.refs-directory", get_path_refs_directory },
> +	{ "path.prefix", get_path_prefix },
>   	{ "path.shallow-file", get_path_shallow_file },
>   	{ "path.superproject-working-tree", get_path_superproject_working_tree },
>   	{ "path.toplevel", get_path_toplevel },
> +	{ "path.work-tree", get_path_work_tree },
>   	{ "references.format", get_references_format },
>   };
>   > @@ -378,7 +353,7 @@ static int cmd_repo_info(int argc, const char **argv, const char *prefix,
>   	enum output_format format = FORMAT_KEYVALUE;
>   	struct repo_info info = {
>   		.repo = repo,
> -		.prefix = prefix,
> +		.prefix = prefix ? prefix : "",
>   		.path_format = PATH_FORMAT_ABSOLUTE,
>   	};
>   	int all_keys = 0;
> diff --git a/t/t1900-repo.sh b/t/t1900-repo.sh
> index dcacf84cc3..2351b772b2 100755
> --- a/t/t1900-repo.sh
> +++ b/t/t1900-repo.sh
> @@ -13,17 +13,15 @@ REPO_INFO_KEYS='
>   	path.common-dir
>   	path.config-file
>   	path.git-dir
> -	path.git-prefix
>   	path.grafts-file
>   	path.hooks-directory
>   	path.index-file
> -	path.logs-directory
>   	path.objects-directory
> -	path.packed-refs-file
> -	path.refs-directory
> +	path.prefix
>   	path.shallow-file
>   	path.superproject-working-tree
>   	path.toplevel
> +	path.work-tree
>   	references.format
>   '
>   > @@ -31,17 +29,15 @@ REPO_INFO_PATH_KEYS='
>   	path.common-dir
>   	path.config-file
>   	path.git-dir
> -	path.git-prefix
>   	path.grafts-file
>   	path.hooks-directory
>   	path.index-file
> -	path.logs-directory
>   	path.objects-directory
> -	path.packed-refs-file
> -	path.refs-directory
> +	path.prefix
>   	path.shallow-file
>   	path.superproject-working-tree
>   	path.toplevel
> +	path.work-tree
>   '
>   >   # Test whether a key-value pair is correctly returned
> @@ -172,12 +168,12 @@ test_expect_success 'path.toplevel is empty in bare repository' '
>   	test_cmp expect actual
>   '
>   > -test_expect_success 'path.git-prefix matches rev-parse --show-prefix' '
> +test_expect_success 'path.prefix matches rev-parse --show-prefix' '
>   	git init path-prefix &&
>   	mkdir -p path-prefix/a/b &&
>   	expected_value=$(git -C path-prefix/a/b rev-parse --show-prefix) &&
> -	echo "path.git-prefix=$expected_value" >expect &&
> -	git -C path-prefix/a/b repo info path.git-prefix >actual &&
> +	echo "path.prefix=$expected_value" >expect &&
> +	git -C path-prefix/a/b repo info path.prefix >actual &&
>   	test_cmp expect actual
>   '
>   > @@ -209,27 +205,27 @@ test_expect_success 'git-path style keys match rev-parse --git-path' '
>   	git -C path-git-path repo info path.config-file >actual &&
>   	test_cmp expect actual &&
>   > -	expected_value=$(git -C path-git-path rev-parse --path-format=absolute --git-path logs) &&
> -	echo "path.logs-directory=$expected_value" >expect &&
> -	git -C path-git-path repo info path.logs-directory >actual &&
> -	test_cmp expect actual &&
> -
> -	expected_value=$(git -C path-git-path rev-parse --path-format=absolute --git-path packed-refs) &&
> -	echo "path.packed-refs-file=$expected_value" >expect &&
> -	git -C path-git-path repo info path.packed-refs-file >actual &&
> -	test_cmp expect actual &&
> -
> -	expected_value=$(git -C path-git-path rev-parse --path-format=absolute --git-path refs) &&
> -	echo "path.refs-directory=$expected_value" >expect &&
> -	git -C path-git-path repo info path.refs-directory >actual &&
> -	test_cmp expect actual &&
> -
>   	expected_value=$(git -C path-git-path rev-parse --path-format=absolute --git-path shallow) &&
>   	echo "path.shallow-file=$expected_value" >expect &&
>   	git -C path-git-path repo info path.shallow-file >actual &&
>   	test_cmp expect actual
>   '
>   > +test_expect_success 'path.work-tree matches path.toplevel' '
> +	git init path-work-tree &&
> +	expected_value=$(git -C path-work-tree rev-parse --show-toplevel) &&
> +	echo "path.work-tree=$expected_value" >expect &&
> +	git -C path-work-tree repo info path.work-tree >actual &&
> +	test_cmp expect actual
> +'
> +
> +test_expect_success 'path.work-tree is empty in bare repository' '
> +	git init --bare bare-path-work-tree &&
> +	echo "path.work-tree=" >expect &&
> +	git -C bare-path-work-tree repo info path.work-tree >actual &&
> +	test_cmp expect actual
> +'
> +
>   test_expect_success 'path.superproject-working-tree is empty when not a submodule' '
>   	git init path-superproject &&
>   	echo "path.superproject-working-tree=" >expect &&