From: Pushkar Singh <pushkarkumarsingh1970@gmail•com>
To: ps@pks•im
Cc: git@vger•kernel.org, gitster@pobox•com, karthiknayak@gmail•com,
lucasseikioshiro@gmail•com, peff@peff•net,
pushkarkumarsingh1970@gmail•com
Subject: Re: [RFC] git repo info: exposing repository paths
Date: Wed, 18 Feb 2026 18:35:11 +0000 [thread overview]
Message-ID: <20260218183511.17195-1-pushkarkumarsingh1970@gmail.com> (raw)
In-Reply-To: <aYxzmjoxQHccqTAl@pks.im>
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
next prev parent reply other threads:[~2026-02-18 18:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-10 14:11 [RFC] git repo info: exposing repository paths Pushkar Singh
2026-02-11 12:18 ` Patrick Steinhardt
2026-02-18 18:35 ` Pushkar Singh [this message]
2026-03-01 13:44 ` [PATCH 0/2] repo info: add path.git-dir and path.common-dir Pushkar Singh
2026-03-01 13:59 ` [PATCH 1/2] repo: add the field path.git-dir Pushkar Singh
2026-03-01 14:03 ` [PATCH 2/2] repo: add the field path.common-dir Pushkar Singh
2026-03-01 16:50 ` [PATCH 0/2] repo info: add path.git-dir and path.common-dir K Jayatheerth
2026-03-01 18:48 ` Lucas Seiki Oshiro
2026-03-01 19:34 ` Pushkar Singh
2026-03-02 16:50 ` Junio C Hamano
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=20260218183511.17195-1-pushkarkumarsingh1970@gmail.com \
--to=pushkarkumarsingh1970@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=karthiknayak@gmail$(echo .)com \
--cc=lucasseikioshiro@gmail$(echo .)com \
--cc=peff@peff$(echo .)net \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox