[RFC] git repo info: exposing repository paths

[RFC] git repo info: exposing repository paths

[Pushkar Singh]

Hi all,

I’ve been looking at the "git repo" command recently, mostly comparing
"git repo info" with what I usually reach for via "git rev-parse".

One thing I noticed is that git repo info currently reports repository
properties like layout and formats, but none of the repository paths
that scripts often need.

For example, as of now:

git rev-parse --git-dir
git rev-parse --common-dir
git rev-parse --git-path hooks

are commonly used by scripts and tooling to figure out where things
actually live on disk.

I wanted to ask whether it would make sense for git repo info to
eventually expose some of these as structured keys, starting with
something minimal like "git-dir".

My idea is not to completely replace rev-parse, but to let "git repo
info" act as a more discoverable, descriptive interface for repository
metadata, including paths, where appropriate.

One question I am unsure about is whether such paths should be
reported as absolute or relative (for example, relative to the working
tree or invocation directory), and whether git-dir would be a
reasonable first step before considering others.

I wanted to ask first before making any changes, and would appreciate
guidance on whether this direction makes sense.

Thanks,
Pushkar

Re: [RFC] git repo info: exposing repository paths

[Patrick Steinhardt]

Hi,

On Tue, Feb 10, 2026 at 07:41:29PM +0530, Pushkar Singh wrote:
> Hi all,
> 
> I’ve been looking at the "git repo" command recently, mostly comparing
> "git repo info" with what I usually reach for via "git rev-parse".
> 
> One thing I noticed is that git repo info currently reports repository
> properties like layout and formats, but none of the repository paths
> that scripts often need.
> 
> For example, as of now:
> 
> git rev-parse --git-dir
> git rev-parse --common-dir
> git rev-parse --git-path hooks
> 
> are commonly used by scripts and tooling to figure out where things
> actually live on disk.
> 
> I wanted to ask whether it would make sense for git repo info to
> eventually expose some of these as structured keys, starting with
> something minimal like "git-dir".

Yes! git-rev-parse(1) has been growing functionality over time that
simply doesn't have anything to do with revisions, so I think it's good
to give such functionality a new home in git-repo(1). This has been kind
of the original idea behind this command.

> My idea is not to completely replace rev-parse, but to let "git repo
> info" act as a more discoverable, descriptive interface for repository
> metadata, including paths, where appropriate.
> 
> One question I am unsure about is whether such paths should be
> reported as absolute or relative (for example, relative to the working
> tree or invocation directory), and whether git-dir would be a
> reasonable first step before considering others.

I know that Lucas had a bunch of thoughts around this. If I remember
correctly, he wanted to add logic that basically allows the caller to
choose whether the paths should be resolved to an absolute path or not.
I've Cc'd him.

Thanks!

Patrick

Re: [RFC] git repo info: exposing repository paths

[Pushkar Singh]

Hi,

On Wed, Feb 11, 2026 at 01:18:34PM +0100, Patrick Steinhardt wrote:
> git-rev-parse(1) has been growing functionality over time that
> simply doesn't have anything to do with revisions, so I think it's good
> to give such functionality a new home in git-repo(1).

I spent some time going through the initial git-repo implementation
thread [1], as well as Lucas's recent WIP series [2] adding
"--format=default" and "--keys" support to "git repo info".

Looking at the current implementation, it seems that adding new values
is primarily done by extending repo_info_fields[]. With the recent
"--keys" support in place, that mechanism feels like the natural place
to expose additional repository metadata.

In that direction, I would like to explore extending the existing
"path.*" namespace with a few additional stable repository paths that
are currently obtained through "git rev-parse", namely:

- path.git-dir
- path.common-dir
- path.objects-dir

These correspond to well-defined repository state and are already
available via helpers such as repo_get_git_dir() and
repo_get_common_dir(). The idea would be to add them as new entries in
repo_info_fields[], reusing the existing output handling, without
introducing new flags or changing the current structure.

For now, I am intentionally avoiding invocation-dependent values such
as "git-prefix" or "is-inside-work-tree", and focusing only on paths
derived directly from the repository instance.

Regarding relative versus absolute semantics, I would follow the
direction of the ongoing "--path-format" discussion and align with
whatever default behavior is agreed upon there.

If this sounds reasonable, I can prototype support for
"path.git-dir" and "path.common-dir" first as a minimal step and
continue the discussion based on that.

Thanks,
Pushkar

[1] Initial git-repo introduction thread:
https://public-inbox.org/git/20250610152117.14826-1-lucasseikioshiro@gmail.com/t/#u

[2] repo: add --format=default and --keys series:
https://lore.kernel.org/git/aZLARuSCuy8wYLUA@pks.im/T/#u

[PATCH 0/2] repo info: add path.git-dir and path.common-dir

[Pushkar Singh]

Hi,

Following the earlier RFC discussion about exposing repository
paths via `git repo info`, this series adds two new fields:

  - path.git-dir
  - path.common-dir

These mirror the information available through
`git rev-parse --git-dir` and `git rev-parse --common-dir`,
respectively.

This series builds on the recent path-related changes to
`git repo info` (including `path.toplevel` and the
`--path-format` flag), which are currently under review.

Both fields respect the `--path-format` semantics introduced
there.

Pushkar Singh (2):
  repo: add the field path.git-dir
  repo: add the field path.common-dir

 builtin/repo.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)


base-commit: 625c4fb2daac9879b299dd1cae2e793d2821dec0
prerequisite-patch-id: a15d35d8ce98f550953b8d2b5766b945ae73013e
prerequisite-patch-id: c3311a175dacc8d31ac8143f6deb36a1a46bd960
prerequisite-patch-id: e2348c7f5cdad006aeb10ddda81a184859941c8c
prerequisite-patch-id: 54003bdf23d570ce671626496a6622319a4ee2c8
-- 
2.43.0

[PATCH 1/2] repo: add the field path.git-dir

[Pushkar Singh]

The flag --git-dir from git-rev-parse is commonly used by
scripts and tooling to retrieve the repository’s Git directory.

Since git repo info aims to provide structured repository
metadata, expose this information via a new field
path.git-dir.

The value respects the --path-format flag introduced earlier.

Signed-off-by: Pushkar Singh <pushkarkumarsingh1970@gmail.com>
---
 builtin/repo.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/builtin/repo.c b/builtin/repo.c
index 61cd539e05..8b4c7ae4cb 100644
--- a/builtin/repo.c
+++ b/builtin/repo.c
@@ -73,6 +73,21 @@ static int get_path_toplevel(struct repository *repo, struct strbuf *buf,
 	return 0;
 }
 
+static int get_path_git_dir(struct repository *repo, struct strbuf *buf,
+				 const char *prefix,
+				 enum path_format_type format)
+{
+	const char *gitdir = repo_get_git_dir(repo);
+
+	if (!gitdir)
+		return error(_("unable to retrieve git directory"));
+
+	strbuf_add_path(buf, gitdir, prefix, format,
+					PATH_DEFAULT_UNMODIFIED);
+
+	return 0;
+}
+
 static int get_references_format(struct repository *repo, struct strbuf *buf,
 				 const char *prefix UNUSED,
 				 enum path_format_type format UNUSED)
@@ -87,6 +102,7 @@ static const struct repo_info_field repo_info_field[] = {
 	{ "layout.bare", get_layout_bare },
 	{ "layout.shallow", get_layout_shallow },
 	{ "object.format", get_object_format },
+	{ "path.git-dir", get_path_git_dir },
 	{ "path.toplevel", get_path_toplevel },
 	{ "references.format", get_references_format },
 };
-- 
2.43.0

[PATCH 2/2] repo: add the field path.common-dir

[Pushkar Singh]

Expose the repository common directory through a new
path.common-dir field in git repo info.

This mirrors the information available via
git rev-parse --common-dir and allows structured
retrieval through the repo subcommand.

The value respects the --path-format flag.

Signed-off-by: Pushkar Singh <pushkarkumarsingh1970@gmail.com>
---
 builtin/repo.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/builtin/repo.c b/builtin/repo.c
index 8b4c7ae4cb..d42ac2478b 100644
--- a/builtin/repo.c
+++ b/builtin/repo.c
@@ -88,6 +88,21 @@ static int get_path_git_dir(struct repository *repo, struct strbuf *buf,
 	return 0;
 }
 
+static int get_path_common_dir(struct repository *repo, struct strbuf *buf,
+				 const char *prefix,
+				 enum path_format_type format)
+{
+	const char *commondir = repo_get_common_dir(repo);
+
+	if (!commondir)
+		return error(_("unable to retrieve common directory"));
+
+	strbuf_add_path(buf, commondir, prefix, format,
+					PATH_DEFAULT_RELATIVE_IF_SHARED);
+
+	return 0;
+}
+
 static int get_references_format(struct repository *repo, struct strbuf *buf,
 				 const char *prefix UNUSED,
 				 enum path_format_type format UNUSED)
@@ -102,6 +117,7 @@ static const struct repo_info_field repo_info_field[] = {
 	{ "layout.bare", get_layout_bare },
 	{ "layout.shallow", get_layout_shallow },
 	{ "object.format", get_object_format },
+	{ "path.common-dir", get_path_common_dir },
 	{ "path.git-dir", get_path_git_dir },
 	{ "path.toplevel", get_path_toplevel },
 	{ "references.format", get_references_format },
-- 
2.43.0

Re: [PATCH 0/2] repo info: add path.git-dir and path.common-dir

[K Jayatheerth]

> Hi,
>

Hey Pushkar,

> Following the earlier RFC discussion about exposing repository
> paths via `git repo info`, this series adds two new fields:
>
>   - path.git-dir
>   - path.common-dir
> > Hi,
>

Hey Pushkar,

> Following the earlier RFC discussion about exposing repository
> paths via `git repo info`, this series adds two new fields:
>
>   - path.git-dir
>   - path.common-dir
>


There are no updates to t/t1900-repo-info.sh.
Since path normalization can be quite tricky across
different OS environments, we absolutely need tests to
verify how path.git-dir and path.common-dir behave
under both --path-format=absolute and --path-format=relative.

For example
In both patches, if the path returns NULL, you return an error(...).
Have you tested how this behaves if a user runs git repo info --all

This is one I could think of...


> These mirror the information available through
> `git rev-parse --git-dir` and `git rev-parse --common-dir`,
> respectively.
>
> This series builds on the recent path-related changes to
> `git repo info` (including `path.toplevel` and the
> `--path-format` flag), which are currently under review.
>
> Both fields respect the `--path-format` semantics introduced
> there.
>

The new keys haven't been added to Documentation/git-repo.adoc.


> Pushkar Singh (2):
>   repo: add the field path.git-dir
>   repo: add the field path.common-dir
>
>  builtin/repo.c | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>
>
> base-commit: 625c4fb2daac9879b299dd1cae2e793d2821dec0
> prerequisite-patch-id: a15d35d8ce98f550953b8d2b5766b945ae73013e
> prerequisite-patch-id: c3311a175dacc8d31ac8143f6deb36a1a46bd960
> prerequisite-patch-id: e2348c7f5cdad006aeb10ddda81a184859941c8c
> prerequisite-patch-id: 54003bdf23d570ce671626496a6622319a4ee2c8
> --
> 2.43.0

Thank you for the patch

Regards
- Jayatheerth



There are no updates to t/t1900-repo-info.sh.
Since path normalization can be quite tricky across
different OS environments, we absolutely need tests to
verify how path.git-dir and path.common-dir behave
under both --path-format=absolute and --path-format=relative.

For example
In both patches, if the path returns NULL, you return an error(...).
Have you tested how this behaves if a user runs git repo info --all

This is one I could think of...


> These mirror the information available through
> `git rev-parse --git-dir` and `git rev-parse --common-dir`,
> respectively.
>
> This series builds on the recent path-related changes to
> `git repo info` (including `path.toplevel` and the
> `--path-format` flag), which are currently under review.
>
> Both fields respect the `--path-format` semantics introduced
> there.
>

The new keys haven't been added to Documentation/git-repo.adoc.


> Pushkar Singh (2):
>   repo: add the field path.git-dir
>   repo: add the field path.common-dir
>
>  builtin/repo.c | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>
>
> base-commit: 625c4fb2daac9879b299dd1cae2e793d2821dec0
> prerequisite-patch-id: a15d35d8ce98f550953b8d2b5766b945ae73013e
> prerequisite-patch-id: c3311a175dacc8d31ac8143f6deb36a1a46bd960
> prerequisite-patch-id: e2348c7f5cdad006aeb10ddda81a184859941c8c
> prerequisite-patch-id: 54003bdf23d570ce671626496a6622319a4ee2c8
> --
> 2.43.0

Thank you for the patch

Regards
- Jayatheerth

Re: [PATCH 0/2] repo info: add path.git-dir and path.common-dir

[Lucas Seiki Oshiro]

> Hi,

Hi!

> Following the earlier RFC discussion about exposing repository
> paths via `git repo info`, this series adds two new fields:
> 
>  - path.git-dir
>  - path.common-dir

It's too early to send this. The first patch wasn't accepted yet
(and I really don't think that it will be in v1)

Re: [PATCH 0/2] repo info: add path.git-dir and path.common-dir

[Pushkar Singh]

Hi Lucas,

> It's too early to send this. The first patch wasn't accepted yet
> (and I really don't think that it will be in v1)

That makes sense...
Thanks for pointing it out.

I will wait until the path-related series stabilizes before iterating
further on top of it. In the meantime, I will hold off on sending a v2
of this series.

Thanks for the guidance.

Pushkar

Re: [PATCH 0/2] repo info: add path.git-dir and path.common-dir

[Junio C Hamano]

Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:

>> Hi,
>
> Hi!
>
>> Following the earlier RFC discussion about exposing repository
>> paths via `git repo info`, this series adds two new fields:
>> 
>>  - path.git-dir
>>  - path.common-dir
>
> It's too early to send this. The first patch wasn't accepted yet
> (and I really don't think that it will be in v1)

What's happening here?  To me, it looks as if many people are
stomping on each others' toes, adding path.something to "repo info"
output on their own without much inter-developer coordination.