threads / rfc / 64970

[RFC] git repo info: exposing repository paths

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

## tl;dr

10 messages between Feb 10, 2026 and Mar 2, 2026.

replies: 9people: 5as markdown or json

Pushkar Singh· Feb 10, 2026, 14:11 UTC · lore
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

Patrick Steinhardt· Feb 11, 2026, 12:18 UTC · re: Pushkar Singh · lore

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

Hi,
On Tue, Feb 10, 2026 at 07:41:29PM +0530, Pushkar Singh wrote:
Show 21 quoted lines
> 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.

Show 8 quoted lines
> 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
Pushkar Singh· Feb 18, 2026, 18:35 UTC · re: Patrick Steinhardt · lore

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

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

Pushkar Singh· Mar 1, 2026, 13:44 UTC · re: Pushkar Singh · lore

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

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
Pushkar Singh· Mar 1, 2026, 13:59 UTC · re: Pushkar Singh · lore

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

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
Pushkar Singh· Mar 1, 2026, 14:03 UTC · re: Pushkar Singh · lore

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

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
K Jayatheerth· Mar 1, 2026, 16:50 UTC · re: Pushkar Singh · lore

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

> Hi,
>
Hey Pushkar,
Show 7 quoted lines
> 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,
Show 6 quoted lines
> 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...
Show 11 quoted lines
> 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.
Show 15 quoted lines
> 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...
Show 11 quoted lines
> 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.
Show 15 quoted lines
> 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
Lucas Seiki Oshiro· Mar 1, 2026, 18:48 UTC · re: Pushkar Singh · lore

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

> Hi,
Hi!
Show 5 quoted lines
> 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)

Pushkar Singh· Mar 1, 2026, 19:34 UTC · re: Lucas Seiki Oshiro · lore

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

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
Junio C Hamano· Mar 2, 2026, 16:50 UTC · re: Lucas Seiki Oshiro · lore

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

Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:
Show 12 quoted lines
>> 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.

← back to recent threads