public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Pushkar Singh <pushkarkumarsingh1970@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Karthik Nayak <karthiknayak@gmail.com>, Jeff King <peff@peff.net>,
	Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
Subject: Re: [RFC] git repo info: exposing repository paths
Date: Wed, 11 Feb 2026 13:18:34 +0100	[thread overview]
Message-ID: <aYxzmjoxQHccqTAl@pks.im> (raw)
In-Reply-To: <CALE2CrTt_2-9C4zCrZPBabtsWY=+Mk-bH4Jaemk=yHtfpoLjfg@mail.gmail.com>

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

  reply	other threads:[~2026-02-11 12:18 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 [this message]
2026-02-18 18:35   ` Pushkar Singh
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=aYxzmjoxQHccqTAl@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthiknayak@gmail.com \
    --cc=lucasseikioshiro@gmail.com \
    --cc=peff@peff.net \
    --cc=pushkarkumarsingh1970@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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