All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin Tobler <jltobler@gmail.com>
To: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
Cc: git@vger.kernel.org, a3205153416@gmail.com, gitster@pobox.com,
	 kumarayushjha123@gmail.com, lucasseikioshiro@gmail.com,
	phillip.wood@dunelm.org.uk,  sandals@crustytoothpaste.net
Subject: Re: [GSoC PATCH v2 3/4] repo: add path.gitdir with absolute and relative suffix formatting
Date: Mon, 8 Jun 2026 13:50:36 -0500	[thread overview]
Message-ID: <aicDOlJdUrgMi3sA@denethor> (raw)
In-Reply-To: <20260605163012.181089-4-jayatheerthkulkarni2005@gmail.com>

On 26/06/05 10:00PM, K Jayatheerth wrote:
> Scripts often need to locate the `.git` directory. While `git rev-parse`
> provides this, it relies on command-line flags to dictate path formatting.
> 
> Introduce `path.gitdir.absolute` and `path.gitdir.relative` keys to
> `git repo info`. Exposing separate format-specific keys instead of a base
> `path.gitdir` key avoids default fallbacks and requires callers to state
> their format requirements explicitly. Both keys use `format_path()` to
> resolve paths.

Makes sense.

> To test these keys, introduce the `test_repo_info_path` helper in
> `t/t1900-repo-info.sh`. The helper evaluates paths dynamically and accepts
> environment variable prefixes. This prepares the test suite for future path
> keys that depend on environment overrides, such as `commondir`.
> 
> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
> Mentored-by: Justin Tobler <jltobler@gmail.com>
> Mentored-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
> ---
>  Documentation/git-repo.adoc |  6 ++++++
>  builtin/repo.c              | 26 ++++++++++++++++++++++++++
>  t/t1900-repo-info.sh        | 33 +++++++++++++++++++++++++++++++++
>  3 files changed, 65 insertions(+)
> 
> diff --git a/Documentation/git-repo.adoc b/Documentation/git-repo.adoc
> index 42262c1983..a0dca7ce88 100644
> --- a/Documentation/git-repo.adoc
> +++ b/Documentation/git-repo.adoc
> @@ -104,6 +104,12 @@ values that they return:
>  `object.format`::
>  	The object format (hash algorithm) used in the repository.
>  
> +`path.gitdir.absolute`::
> +	The canonical absolute path to the Git repository directory (the `.git` directory).
> +
> +`path.gitdir.relative`::
> +	The path to the Git repository directory relative to the current working directory.
> +
>  `references.format`::
>  	The reference storage format. The valid values are:
>  +
> diff --git a/builtin/repo.c b/builtin/repo.c
> index 71a5c1c29c..6e97f6a0e4 100644
> --- a/builtin/repo.c
> +++ b/builtin/repo.c
> @@ -7,12 +7,14 @@
>  #include "hex.h"
>  #include "odb.h"
>  #include "parse-options.h"
> +#include "path.h"
>  #include "path-walk.h"
>  #include "progress.h"
>  #include "quote.h"
>  #include "ref-filter.h"
>  #include "refs.h"
>  #include "revision.h"
> +#include "setup.h"
>  #include "strbuf.h"
>  #include "string-list.h"
>  #include "shallow.h"
> @@ -75,6 +77,28 @@ static int get_object_format(struct repository *repo, struct strbuf *buf)
>  	return 0;
>  }
>  
> +static int get_path_gitdir_absolute(struct repository *repo, struct strbuf *buf)
> +{
> +	const char *git_dir = repo_get_git_dir(repo);
> +
> +	if (!git_dir)
> +		return error(_("unable to get git directory"));
> +
> +	format_path(buf, git_dir, startup_info->prefix, PATH_FORMAT_CANONICAL);

For absolute paths, I don't think we actually need the prefix, but
providing it doesn't probably matter too much either way.

> +	return 0;
> +}
> +
> +static int get_path_gitdir_relative(struct repository *repo, struct strbuf *buf)
> +{
> +	const char *git_dir = repo_get_git_dir(repo);
> +
> +	if (!git_dir)
> +		return error(_("unable to get git directory"));
> +
> +	format_path(buf, git_dir, startup_info->prefix, PATH_FORMAT_RELATIVE);
> +	return 0;
> +}

Looks good.

> +
>  static int get_references_format(struct repository *repo, struct strbuf *buf)
>  {
>  	strbuf_addstr(buf,
> @@ -87,6 +111,8 @@ 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.gitdir.absolute", get_path_gitdir_absolute },
> +	{ "path.gitdir.relative", get_path_gitdir_relative },
>  	{ "references.format", get_references_format },
>  };
>  
> diff --git a/t/t1900-repo-info.sh b/t/t1900-repo-info.sh
> index 39bb77dda0..0660b00bbc 100755
> --- a/t/t1900-repo-info.sh
> +++ b/t/t1900-repo-info.sh
> @@ -155,4 +155,37 @@ test_expect_success 'git repo info -h shows only repo info usage' '
>  	test_grep ! "git repo structure" actual
>  '
>  
> +test_repo_info_path () {
> +	field_name=$1
> +	expect_absolute_eval=$2
> +	expect_relative=$3
> +	env_prefix=$4

nit: I was a bit uncertain regarding the purpose of env_prefix here.
Since the env_prefix is not used by any tests yet, I wonder if it we
should delay adding it until the next patch. If we want to reduce churn
though, I think we could also swap the order of patch 3 and 4.

> +
> +	test_expect_success "query individual key: path.$field_name.absolute${env_prefix:+ ($env_prefix)}" '
> +		(
> +			cd test-repo/sub &&
> +			expect_absolute=$(eval "$expect_absolute_eval") &&

Can we just compute `expect_absolute` prior to passing it instead of
using eval here?

> +			echo "path.$field_name.absolute=$expect_absolute" >expect &&
> +			eval "${env_prefix:+$env_prefix }git repo info \"path.$field_name.absolute\"" >actual &&
> +			test_cmp expect actual
> +		)
> +	'
> +
> +	test_expect_success "query individual key: path.$field_name.relative${env_prefix:+ ($env_prefix)}" '
> +		(
> +			cd test-repo/sub &&
> +			echo "path.$field_name.relative=$expect_relative" >expect &&
> +			eval "${env_prefix:+$env_prefix }git repo info \"path.$field_name.relative\"" >actual &&
> +			test_cmp expect actual
> +		)
> +	'
> +}
> +
> +test_expect_success 'setup test repository layout for path fields' '
> +	git init test-repo &&
> +	mkdir -p test-repo/sub
> +'
> +
> +test_repo_info_path 'gitdir' 'echo "$(cd .. && pwd)/.git"' '../.git'

hmmm, do we expect the path suffix to be the same between relative and
absolute paths for all test cases? If so, we could just have a single
`expect_path_suffix` argument and let the helper compute the appropriate
absolute and relative paths internally.

-Justin

  reply	other threads:[~2026-06-08 18:50 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01 15:19 [GSoC][PATCH 0/4] teach git repo info to handle path keys K Jayatheerth
2026-06-01 15:19 ` [GSoC][PATCH 1/4] path: add strbuf_add_path for formatting paths K Jayatheerth
2026-06-02 13:00   ` Phillip Wood
2026-06-01 15:19 ` [GSoC][PATCH 2/4] rev-parse: use strbuf_add_path for path formatting K Jayatheerth
2026-06-01 15:19 ` [GSoC][PATCH 3/4] repo: add path.gitdir with absolute and relative suffix formatting K Jayatheerth
2026-06-01 16:28   ` Lucas Seiki Oshiro
2026-06-01 23:09     ` Junio C Hamano
2026-06-01 15:19 ` [GSoC][PATCH 4/4] repo: add path.commondir " K Jayatheerth
2026-06-01 16:34   ` Lucas Seiki Oshiro
2026-06-01 21:58   ` Lucas Seiki Oshiro
2026-06-01 16:25 ` [GSoC][PATCH 0/4] teach git repo info to handle path keys Lucas Seiki Oshiro
2026-06-01 22:04 ` Lucas Seiki Oshiro
2026-06-01 23:05 ` Junio C Hamano
2026-06-02 13:03 ` Phillip Wood
2026-06-05 16:30 ` [GSoC PATCH v2 " K Jayatheerth
2026-06-05 16:30   ` [GSoC PATCH v2 1/4] path: introduce format_path() for centralized path formatting K Jayatheerth
2026-06-05 16:55     ` Kristoffer Haugsbakk
2026-06-09  2:27       ` K Jayatheerth
2026-06-08 15:05     ` Lucas Seiki Oshiro
2026-06-09  2:47       ` K Jayatheerth
2026-06-08 17:28     ` Justin Tobler
2026-06-05 16:30   ` [GSoC PATCH v2 2/4] rev-parse: use format_path for " K Jayatheerth
2026-06-08 17:54     ` Justin Tobler
2026-06-05 16:30   ` [GSoC PATCH v2 3/4] repo: add path.gitdir with absolute and relative suffix formatting K Jayatheerth
2026-06-08 18:50     ` Justin Tobler [this message]
2026-06-09  4:41       ` K Jayatheerth
2026-06-08 22:17     ` Lucas Seiki Oshiro
2026-06-05 16:30   ` [GSoC PATCH v2 4/4] repo: add path.commondir " K Jayatheerth
2026-06-08 22:40     ` Lucas Seiki Oshiro
2026-06-05 17:35   ` [GSoC PATCH v2 0/4] teach git repo info to handle path keys Lucas Seiki Oshiro
2026-06-09  2:30     ` K Jayatheerth
2026-06-08 22:36   ` Junio C Hamano
2026-06-09  5:00     ` K Jayatheerth

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=aicDOlJdUrgMi3sA@denethor \
    --to=jltobler@gmail.com \
    --cc=a3205153416@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jayatheerthkulkarni2005@gmail.com \
    --cc=kumarayushjha123@gmail.com \
    --cc=lucasseikioshiro@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=sandals@crustytoothpaste.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.