Re: [PATCH v3 1/7] repo: add path.toplevel with absolute and relative suffix formatting

>
> On 26/07/26 04:13PM, K Jayatheerth wrote:
> > Scripts frequently need to find the root directory of a repository's
> > working tree. Currently, this requires using `git rev-parse --show-toplevel`
> > or inferring it from other path components.
> >
> > Introduce `path.toplevel.absolute` and `path.toplevel.relative` keys
> > to `git repo info`. This allows scripts to retrieve the top-level
> > working tree path in a predictable, strictly formatted manner without
> > relying on `rev-parse`.
>
> Ok, this seems like suitable information to also look up under
> git-repo-info.
>
> > If requested in a bare repository where no working tree exists, the
> > command returns an empty string.
>
> This matches the existing behavior in git-rev-parse(1). Makes sense.
>

> >
> > +static int get_path_toplevel_absolute(struct repository *repo, struct strbuf *buf)
> > +{
> > +     const char *work_tree = repo_get_work_tree(repo);
> > +
> > +     if (!work_tree) {
> > +             strbuf_addstr(buf, "");
>
> The strbuf here is already NULL-terminated when its initialized. I don't
> think this should be necessary.
>

> > +     if (!work_tree) {
> > +             strbuf_addstr(buf, "");
>
> Same here.
>

> > +test_expect_success 'path.toplevel returns empty in a bare repository' '
> > +     test_when_finished "rm -rf bare.git" &&
> > +     git init --bare bare.git &&
> > +     (
> > +             cd bare.git &&
> > +             echo "path.toplevel.absolute=" >expect &&
> > +             git repo info path.toplevel.absolute >actual &&
> > +             test_cmp expect actual
>
> In this test we are only checking the absolute path. It probably
> wouldn't hurt to also check the relative path too.
>

> > Introduce `path.superproject-working-tree.absolute` and
> > `path.superproject-working-tree.relative` keys to `git repo info`.
> > This exposes the core submodule context via a scriptable config-like key
> > using standard format rules.
>
> Ok, this also seems like a good fit to include as a key in
> git-repo-info, but "superproject-working-tree" is a bit of a mouthful
> IMO. An alternative could potentially be "superproject-root"? Maybe its
> best to just be consistent with the option name in git-rev-parse(1) and
> keep it the same though.

> > +static int get_path_superproject_absolute(struct repository *repo UNUSED, struct strbuf *buf)
> > +{
> > +     struct strbuf superproject = STRBUF_INIT;
> > +
> > +     if (!get_superproject_working_tree(&superproject)) {
> > +             strbuf_release(&superproject);
> > +             strbuf_addstr(buf, "");
>
> Same comment here as in the previous patch...
>
> > +     struct strbuf superproject = STRBUF_INIT;
> > +
> > +     if (!get_superproject_working_tree(&superproject)) {
> > +             strbuf_release(&superproject);
> > +             strbuf_addstr(buf, "");
>
> ...and here as well...
>
> > +             return 0;
> > +     }
> > +
> > +     format_path(buf, superproject.buf, startup_info->prefix, PATH_FORMAT_RELATIVE);
> > +     strbuf_release(&superproject);
> > +     return 0;
> > +}
> > +
> > +test_expect_success 'path.superproject-working-tree returns empty when not in a submodule' '
> > +     test_when_finished "rm -rf repo" &&
> > +     git init repo &&
> > +     (
> > +             cd repo &&
> > +             echo "path.superproject-working-tree.absolute=" >expect &&
> > +             git repo info path.superproject-working-tree.absolute >actual &&
> > +             test_cmp expect actual
>
> ... and here as well. :)
>

> > Tools and deployment hooks frequently query the location of the object
> > database directory. Currently, this relies on legacy parsing methods or
> > manually inspecting `git rev-parse --git-path objects`.
>
> "Tools and deployment hooks" seems a bit overly specific. Maybe instead
> we could just say "Scripts operating on a repository may need to query
> the location of the object database directory"?
>

> > Introduce `path.objects.absolute` and `path.objects.relative` keys to
> > `git repo info`. This allows tools to discover the object database
> > location safely while natively adhering to active `GIT_OBJECT_DIRECTORY`
> > environment variable overrides.
>
> In the context of pluggable ODBs, this proposed key is a little more
> interesting because a non-"files" ODB source in the future may not even
> have a filesystem path to an objects directory. When this becomes more
> relevant, we could just adapt these keys to return an empty string in
> such cases, but it does also make me question whether it is information
> that we should further expose in the first place if it does eventually
> becomes an internal detail of a specific ODB source.
>
> It probably doesn't matter too much, but I've CC'd Patrick for his
> thoughts too.
>

> > +static int get_path_objects_absolute(struct repository *repo, struct strbuf *buf)
> > +{
> > +     const char *obj_dir = repo_get_object_directory(repo);
> > +
> > +     if (!obj_dir)
> > +             return error(_("unable to get object directory"));
> > +
> > +     format_path(buf, obj_dir, startup_info->prefix, PATH_FORMAT_CANONICAL);
>
> For the absolute path, do we actually need to provide the prefix? It
> might make it more clear that its the aboslute path if we just pass ""
> instead?
>

>
> On 26/07/26 04:13PM, K Jayatheerth wrote:
> > External tool integrations and validation systems need a stable way to
> > identify where the repository hooks are stored. Currently, this involves
> > relying on `git rev-parse --git-path hooks` or querying `core.hooksPath`
> > manually.
>
> Similar to the comment in the previous patch, "External tool
> intergations and validation systems" seems overly specific IMO. Also,
> "need" is a bit strongly worded as I'm sure its not a requirement for
> every external script/tool.
>

> > Introduce `path.hooks.absolute` and `path.hooks.relative` keys to
> > `git repo info`. This allows tools to discover the active hooks location
> > natively, ensuring proper resolution regardless of whether Git is using
> > the standard `.git/hooks` structure or a custom `core.hooksPath` setup.
>
> Per hooks path documentation:
>
>   The path can be either absolute or relative. A relative path is taken
>   as relative to the directory where the hooks are run.
>
>   ...
>
>   You  can also disable all hooks entirely by setting core.hooksPath to
>   /dev/null.
>
> Should we handle this /dev/null case specially? It looks like:
>
>   $ git -c core.hooksPath=/dev/null rev-parse --git-path hooks
>
> just prints '/dev/null'. I do wonder if this makes much sense though in
> context of the relative path version of this key. From some quick
> testing, it appears the git-rev-parse(1) version of this option always
> prints the absolute path if that is what is configured (it appears to
> ignore --path-format). Maybe we should just special case /dev/null and
> return an empty string? I'm not entirely sure what the best route is
> here though.
>