{"thread":{"id":"65417","subject":"[PATCH] repo: add paths.toplevel to repo info","startedAt":"2026-04-02T17:14:25Z","lastAt":"2026-04-09T16:01:49Z","messageCount":8,"participants":["Jayesh Daga via GitGitGadget","Junio C Hamano","Karthik Nayak"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"540778","messageId":"pull.2264.git.git.1775150062407.gitgitgadget@gmail.com","threadId":"65417","inReplyTo":null,"subject":"[PATCH] repo: add paths.toplevel to repo info","fromName":"Jayesh Daga via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-04-02T17:14:22Z","receivedAt":"2026-04-02T17:14:25Z","isPatch":true,"body":"From: Jayesh Daga <jayeshdaga99@gmail.com>\n\nExpose the working tree root via `git repo info` as\npaths.toplevel, matching the semantics of\n`git rev-parse --show-toplevel`.\n\nFor bare repositories, this value is empty, consistent\nwith other non-applicable fields.\n\nThis allows scripts to retrieve the repository root\nthrough a structured interface without invoking\nrev-parse.\n\nSigned-off-by: Jayesh Daga <jayeshdaga99@gmail.com>\n---\n    repo: add paths.toplevel to repo info\n    \n    repo info currently does not expose the repository's working tree root,\n    even though this information is available via repo_get_work_tree().\n    \n    This makes it harder for scripts to retrieve the repository root through\n    a structured interface, often requiring the use of git rev-parse\n    --show-toplevel.\n    \n    Add a new field paths.toplevel to git repo info that returns the working\n    tree root. For bare repositories, this value is empty, consistent with\n    other non-applicable fields.\n    \n    This provides a consistent and script-friendly way to query repository\n    paths without invoking additional commands.\n    \n    Signed-off-by: Jayesh Daga jayeshdaga99@gmail.com\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2264%2Fjayesh0104%2Frepo-toplevel-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2264/jayesh0104/repo-toplevel-v1\nPull-Request: https://github.com/git/git/pull/2264\n\n builtin/repo.c       | 12 ++++++++++++\n t/t1900-repo-info.sh | 16 ++++++++++++++++\n 2 files changed, 28 insertions(+)\n\ndiff --git a/builtin/repo.c b/builtin/repo.c\nindex 71a5c1c29c..d0491f6c66 100644\n--- a/builtin/repo.c\n+++ b/builtin/repo.c\n@@ -62,6 +62,17 @@ static int get_layout_bare(struct repository *repo UNUSED, struct strbuf *buf)\n \treturn 0;\n }\n \n+static int get_paths_toplevel(struct repository *repo, struct strbuf *buf)\n+{\n+    const char *wt = repo_get_work_tree(repo);\n+\n+    if (!wt)\n+\treturn -1; /* match existing error style */\n+\n+    strbuf_addstr(buf, wt);\n+    return 0;\n+}\n+\n static int get_layout_shallow(struct repository *repo, struct strbuf *buf)\n {\n \tstrbuf_addstr(buf,\n@@ -87,6 +98,7 @@ static const struct repo_info_field repo_info_field[] = {\n \t{ \"layout.bare\", get_layout_bare },\n \t{ \"layout.shallow\", get_layout_shallow },\n \t{ \"object.format\", get_object_format },\n+\t{ \"paths.toplevel\", get_paths_toplevel },\n \t{ \"references.format\", get_references_format },\n };\n \ndiff --git a/t/t1900-repo-info.sh b/t/t1900-repo-info.sh\nindex 39bb77dda0..470e06e8c2 100755\n--- a/t/t1900-repo-info.sh\n+++ b/t/t1900-repo-info.sh\n@@ -155,4 +155,20 @@ test_expect_success 'git repo info -h shows only repo info usage' '\n \ttest_grep ! \"git repo structure\" actual\n '\n \n+test_expect_success 'repo info paths.toplevel' '\n+    git repo info paths.toplevel >actual &&\n+    echo \"paths.toplevel=$(git rev-parse --show-toplevel)\" >expected &&\n+    test_cmp expected actual\n+'\n+\n+test_expect_success 'repo info paths.toplevel (bare repo)' '\n+    git init --bare bare.git &&\n+    (\n+\tcd bare.git &&\n+\tgit repo info paths.toplevel >actual &&\n+\techo \"paths.toplevel=\" >expected &&\n+\ttest_cmp expected actual\n+    )\n+'\n+\n test_done\n\nbase-commit: 256554692df0685b45e60778b08802b720880c50\n-- \ngitgitgadget\n"},{"id":"540779","messageId":"xmqqpl4hqn2w.fsf@gitster.g","threadId":"65417","inReplyTo":"pull.2264.git.git.1775150062407.gitgitgadget@gmail.com","subject":"Re: [PATCH] repo: add paths.toplevel to repo info","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-02T17:38:47Z","receivedAt":"2026-04-02T17:38:50Z","isPatch":true,"body":"\"Jayesh Daga via GitGitGadget\" <gitgitgadget@gmail.com> writes:\n\n> +static int get_paths_toplevel(struct repository *repo, struct strbuf *buf)\n> +{\n> +    const char *wt = repo_get_work_tree(repo);\n> +\n> +    if (!wt)\n> +\treturn -1; /* match existing error style */\n> +\n> +    strbuf_addstr(buf, wt);\n> +    return 0;\n> +}\n\nFunny indentation.  In our C codebase, one level of indent is one\nhorizontal tab \"\\t\".\n\n> @@ -87,6 +98,7 @@ static const struct repo_info_field repo_info_field[] = {\n>  \t{ \"layout.bare\", get_layout_bare },\n>  \t{ \"layout.shallow\", get_layout_shallow },\n>  \t{ \"object.format\", get_object_format },\n> +\t{ \"paths.toplevel\", get_paths_toplevel },\n>  \t{ \"references.format\", get_references_format },\n\nInstead of adding yet another one as people think of it, can we\nfirst take an inventory of what is available from the kitchen-sink\noptions of \"git rev-parse\" and make a list, to be compared with what\nis available in repo_info_field[]?  Add that correspondence table in\na comment before the definition of this array, and it is perfectly\nOK if the right hand side on many rows say \"missing\", like\n\n    /*\n     * rev-parse --<opt>\trepo info <field>\n     *\n     * is-bare-repository\tlayout.bare\n     * is-shallow-repository    layout.shallow\n     * show-cdup\t\t<missing>\n     * show-prefix              <missing>\n     * show-object-format       object.format\n     * show-ref-format          references.format\n     * ... more ...\n     */\n\nThere can be two classes of <missing>, ones that we want to have but\nhaven't been implemented eyt, and others that we do not think we\nneed.\n\nAlso, we may not want to limit the existing sources of information\nto \"rev-parse\", in which case lines of such a correspondence table\nmay need to be grouped by where each piece of information is found\nelsewhere.\n\n>  };\n>  \n> diff --git a/t/t1900-repo-info.sh b/t/t1900-repo-info.sh\n> index 39bb77dda0..470e06e8c2 100755\n> --- a/t/t1900-repo-info.sh\n> +++ b/t/t1900-repo-info.sh\n> @@ -155,4 +155,20 @@ test_expect_success 'git repo info -h shows only repo info usage' '\n>  \ttest_grep ! \"git repo structure\" actual\n>  '\n>  \n> +test_expect_success 'repo info paths.toplevel' '\n> +    git repo info paths.toplevel >actual &&\n> +    echo \"paths.toplevel=$(git rev-parse --show-toplevel)\" >expected &&\n> +    test_cmp expected actual\n> +'\n> +\n> +test_expect_success 'repo info paths.toplevel (bare repo)' '\n> +    git init --bare bare.git &&\n> +    (\n> +\tcd bare.git &&\n> +\tgit repo info paths.toplevel >actual &&\n> +\techo \"paths.toplevel=\" >expected &&\n> +\ttest_cmp expected actual\n> +    )\n> +'\n> +\n>  test_done\n>\n> base-commit: 256554692df0685b45e60778b08802b720880c50\n"},{"id":"541151","messageId":"pull.2264.v2.git.git.1775668134796.gitgitgadget@gmail.com","threadId":"65417","inReplyTo":"pull.2264.git.git.1775150062407.gitgitgadget@gmail.com","subject":"[PATCH v2] repo: add paths.toplevel to repo info","fromName":"Jayesh Daga via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-04-08T17:08:54Z","receivedAt":"2026-04-08T17:08:57Z","isPatch":true,"body":"From: Jayesh Daga <jayeshdaga99@gmail.com>\n\nrepo info currently does not expose the repository's\nworking tree root, even though this information is\navailable via `repo_get_work_tree()` and\n`git rev-parse --show-toplevel`.\n\nAdd a new field `paths.toplevel` to expose this value.\n\nWhile doing so, document the correspondence between\n`git rev-parse` options and `repo info` fields to make\nit easier to identify missing or future additions.\n\nFor bare repositories, this value is empty, consistent\nwith other non-applicable fields.\n\nSigned-off-by: Jayesh Daga [jayeshdaga99@gmail.com](mailto:jayeshdaga99@gmail.com)\n---\n    repo: add paths.toplevel to repo info\n    \n    repo info currently does not expose the repository's working tree root,\n    even though this information is available via repo_get_work_tree().\n    \n    This makes it harder for scripts to retrieve the repository root through\n    a structured interface, often requiring the use of git rev-parse\n    --show-toplevel.\n    \n    Add a new field paths.toplevel to git repo info that returns the working\n    tree root. For bare repositories, this value is empty, consistent with\n    other non-applicable fields.\n    \n    This provides a consistent and script-friendly way to query repository\n    paths without invoking additional commands.\n    \n    Signed-off-by: Jayesh Daga jayeshdaga99@gmail.com\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2264%2Fjayesh0104%2Frepo-toplevel-v2\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2264/jayesh0104/repo-toplevel-v2\nPull-Request: https://github.com/git/git/pull/2264\n\nRange-diff vs v1:\n\n 1:  448dfae6a1 ! 1:  05e34bfe2c repo: add paths.toplevel to repo info\n     @@ Metadata\n       ## Commit message ##\n          repo: add paths.toplevel to repo info\n      \n     -    Expose the working tree root via `git repo info` as\n     -    paths.toplevel, matching the semantics of\n     +    repo info currently does not expose the repository's\n     +    working tree root, even though this information is\n     +    available via `repo_get_work_tree()` and\n          `git rev-parse --show-toplevel`.\n      \n     +    Add a new field `paths.toplevel` to expose this value.\n     +\n     +    While doing so, document the correspondence between\n     +    `git rev-parse` options and `repo info` fields to make\n     +    it easier to identify missing or future additions.\n     +\n          For bare repositories, this value is empty, consistent\n          with other non-applicable fields.\n      \n     -    This allows scripts to retrieve the repository root\n     -    through a structured interface without invoking\n     -    rev-parse.\n     -\n     -    Signed-off-by: Jayesh Daga <jayeshdaga99@gmail.com>\n     +    Signed-off-by: Jayesh Daga [jayeshdaga99@gmail.com](mailto:jayeshdaga99@gmail.com)\n      \n       ## builtin/repo.c ##\n      @@ builtin/repo.c: static int get_layout_bare(struct repository *repo UNUSED, struct strbuf *buf)\n\n\n builtin/repo.c       | 12 ++++++++++++\n t/t1900-repo-info.sh | 16 ++++++++++++++++\n 2 files changed, 28 insertions(+)\n\ndiff --git a/builtin/repo.c b/builtin/repo.c\nindex 71a5c1c29c..d0491f6c66 100644\n--- a/builtin/repo.c\n+++ b/builtin/repo.c\n@@ -62,6 +62,17 @@ static int get_layout_bare(struct repository *repo UNUSED, struct strbuf *buf)\n \treturn 0;\n }\n \n+static int get_paths_toplevel(struct repository *repo, struct strbuf *buf)\n+{\n+    const char *wt = repo_get_work_tree(repo);\n+\n+    if (!wt)\n+\treturn -1; /* match existing error style */\n+\n+    strbuf_addstr(buf, wt);\n+    return 0;\n+}\n+\n static int get_layout_shallow(struct repository *repo, struct strbuf *buf)\n {\n \tstrbuf_addstr(buf,\n@@ -87,6 +98,7 @@ static const struct repo_info_field repo_info_field[] = {\n \t{ \"layout.bare\", get_layout_bare },\n \t{ \"layout.shallow\", get_layout_shallow },\n \t{ \"object.format\", get_object_format },\n+\t{ \"paths.toplevel\", get_paths_toplevel },\n \t{ \"references.format\", get_references_format },\n };\n \ndiff --git a/t/t1900-repo-info.sh b/t/t1900-repo-info.sh\nindex 39bb77dda0..470e06e8c2 100755\n--- a/t/t1900-repo-info.sh\n+++ b/t/t1900-repo-info.sh\n@@ -155,4 +155,20 @@ test_expect_success 'git repo info -h shows only repo info usage' '\n \ttest_grep ! \"git repo structure\" actual\n '\n \n+test_expect_success 'repo info paths.toplevel' '\n+    git repo info paths.toplevel >actual &&\n+    echo \"paths.toplevel=$(git rev-parse --show-toplevel)\" >expected &&\n+    test_cmp expected actual\n+'\n+\n+test_expect_success 'repo info paths.toplevel (bare repo)' '\n+    git init --bare bare.git &&\n+    (\n+\tcd bare.git &&\n+\tgit repo info paths.toplevel >actual &&\n+\techo \"paths.toplevel=\" >expected &&\n+\ttest_cmp expected actual\n+    )\n+'\n+\n test_done\n\nbase-commit: 256554692df0685b45e60778b08802b720880c50\n-- \ngitgitgadget\n"},{"id":"541215","messageId":"pull.2264.v3.git.git.1775714492944.gitgitgadget@gmail.com","threadId":"65417","inReplyTo":"pull.2264.v2.git.git.1775668134796.gitgitgadget@gmail.com","subject":"[PATCH v3] repo: add paths.toplevel to repo info","fromName":"Jayesh Daga via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-04-09T06:01:32Z","receivedAt":"2026-04-09T06:01:36Z","isPatch":true,"body":"From: Jayesh Daga <jayeshdaga99@gmail.com>\n\nrepo info currently does not expose the repository's\nworking tree root, even though this information is\navailable via `repo_get_work_tree()` and\n`git rev-parse --show-toplevel`.\n\nAdd a new field `paths.toplevel` to expose this value.\n\nWhile doing so, document the correspondence between\n`git rev-parse` options and `repo info` fields to make\nit easier to identify missing or future additions.\n\nFor bare repositories, this value is empty, consistent\nwith other non-applicable fields.\n\nSigned-off-by: Jayesh Daga jayeshdaga99@gmail.com\n---\n    repo: add paths.toplevel to repo info\n    \n    repo info currently does not expose the repository's working tree root,\n    even though this information is available via repo_get_work_tree().\n    \n    This makes it harder for scripts to retrieve the repository root through\n    a structured interface, often requiring the use of git rev-parse\n    --show-toplevel.\n    \n    Add a new field paths.toplevel to git repo info that returns the working\n    tree root. For bare repositories, this value is empty, consistent with\n    other non-applicable fields.\n    \n    This provides a consistent and script-friendly way to query repository\n    paths without invoking additional commands.\n    \n    Signed-off-by: Jayesh Daga jayeshdaga99@gmail.com\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2264%2Fjayesh0104%2Frepo-toplevel-v3\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2264/jayesh0104/repo-toplevel-v3\nPull-Request: https://github.com/git/git/pull/2264\n\nRange-diff vs v2:\n\n 1:  05e34bfe2c ! 1:  8a58b6ce03 repo: add paths.toplevel to repo info\n     @@ Commit message\n          For bare repositories, this value is empty, consistent\n          with other non-applicable fields.\n      \n     -    Signed-off-by: Jayesh Daga [jayeshdaga99@gmail.com](mailto:jayeshdaga99@gmail.com)\n     +    Signed-off-by: Jayesh Daga jayeshdaga99@gmail.com\n      \n       ## builtin/repo.c ##\n      @@ builtin/repo.c: static int get_layout_bare(struct repository *repo UNUSED, struct strbuf *buf)\n     @@ builtin/repo.c: static int get_layout_bare(struct repository *repo UNUSED, struc\n       \n      +static int get_paths_toplevel(struct repository *repo, struct strbuf *buf)\n      +{\n     -+    const char *wt = repo_get_work_tree(repo);\n     ++\tconst char *wt = repo_get_work_tree(repo);\n      +\n     -+    if (!wt)\n     -+\treturn -1; /* match existing error style */\n     ++\tif (!wt)\n     ++\t\treturn -1; /* match existing error style */\n      +\n     -+    strbuf_addstr(buf, wt);\n     -+    return 0;\n     ++\tstrbuf_addstr(buf, wt);\n     ++\treturn 0;\n      +}\n      +\n       static int get_layout_shallow(struct repository *repo, struct strbuf *buf)\n       {\n       \tstrbuf_addstr(buf,\n     -@@ builtin/repo.c: static const struct repo_info_field repo_info_field[] = {\n     +@@ builtin/repo.c: static int get_references_format(struct repository *repo, struct strbuf *buf)\n     + \treturn 0;\n     + }\n     + \n     ++/*\n     ++ * rev-parse --<opt>        repo info <field>\n     ++ *\n     ++ * is-bare-repository      layout.bare\n     ++ * is-shallow-repository   layout.shallow\n     ++ * show-object-format      object.format\n     ++ * show-ref-format         references.format\n     ++ * show-toplevel           paths.toplevel\n     ++ *\n     ++ * show-cdup               <missing>\n     ++ * show-prefix             <missing>\n     ++ *\n     ++ * Some <missing> entries may be candidates for future\n     ++ * implementation, while others may not be needed.\n     ++ */\n     ++\n     + /* repo_info_field keys must be in lexicographical order */\n     + static const struct repo_info_field repo_info_field[] = {\n       \t{ \"layout.bare\", get_layout_bare },\n       \t{ \"layout.shallow\", get_layout_shallow },\n       \t{ \"object.format\", get_object_format },\n\n\n builtin/repo.c       | 28 ++++++++++++++++++++++++++++\n t/t1900-repo-info.sh | 16 ++++++++++++++++\n 2 files changed, 44 insertions(+)\n\ndiff --git a/builtin/repo.c b/builtin/repo.c\nindex 71a5c1c29c..8c9afc1150 100644\n--- a/builtin/repo.c\n+++ b/builtin/repo.c\n@@ -62,6 +62,17 @@ static int get_layout_bare(struct repository *repo UNUSED, struct strbuf *buf)\n \treturn 0;\n }\n \n+static int get_paths_toplevel(struct repository *repo, struct strbuf *buf)\n+{\n+\tconst char *wt = repo_get_work_tree(repo);\n+\n+\tif (!wt)\n+\t\treturn -1; /* match existing error style */\n+\n+\tstrbuf_addstr(buf, wt);\n+\treturn 0;\n+}\n+\n static int get_layout_shallow(struct repository *repo, struct strbuf *buf)\n {\n \tstrbuf_addstr(buf,\n@@ -82,11 +93,28 @@ static int get_references_format(struct repository *repo, struct strbuf *buf)\n \treturn 0;\n }\n \n+/*\n+ * rev-parse --<opt>        repo info <field>\n+ *\n+ * is-bare-repository      layout.bare\n+ * is-shallow-repository   layout.shallow\n+ * show-object-format      object.format\n+ * show-ref-format         references.format\n+ * show-toplevel           paths.toplevel\n+ *\n+ * show-cdup               <missing>\n+ * show-prefix             <missing>\n+ *\n+ * Some <missing> entries may be candidates for future\n+ * implementation, while others may not be needed.\n+ */\n+\n /* repo_info_field keys must be in lexicographical order */\n static const struct repo_info_field repo_info_field[] = {\n \t{ \"layout.bare\", get_layout_bare },\n \t{ \"layout.shallow\", get_layout_shallow },\n \t{ \"object.format\", get_object_format },\n+\t{ \"paths.toplevel\", get_paths_toplevel },\n \t{ \"references.format\", get_references_format },\n };\n \ndiff --git a/t/t1900-repo-info.sh b/t/t1900-repo-info.sh\nindex 39bb77dda0..470e06e8c2 100755\n--- a/t/t1900-repo-info.sh\n+++ b/t/t1900-repo-info.sh\n@@ -155,4 +155,20 @@ test_expect_success 'git repo info -h shows only repo info usage' '\n \ttest_grep ! \"git repo structure\" actual\n '\n \n+test_expect_success 'repo info paths.toplevel' '\n+    git repo info paths.toplevel >actual &&\n+    echo \"paths.toplevel=$(git rev-parse --show-toplevel)\" >expected &&\n+    test_cmp expected actual\n+'\n+\n+test_expect_success 'repo info paths.toplevel (bare repo)' '\n+    git init --bare bare.git &&\n+    (\n+\tcd bare.git &&\n+\tgit repo info paths.toplevel >actual &&\n+\techo \"paths.toplevel=\" >expected &&\n+\ttest_cmp expected actual\n+    )\n+'\n+\n test_done\n\nbase-commit: 256554692df0685b45e60778b08802b720880c50\n-- \ngitgitgadget\n"},{"id":"541263","messageId":"CAOLa=ZRo2qWES4XW3UuDxe1Wjew_z7PDy48qQdsjQzD=G8E2ew@mail.gmail.com","threadId":"65417","inReplyTo":"pull.2264.v3.git.git.1775714492944.gitgitgadget@gmail.com","subject":"Re: [PATCH v3] repo: add paths.toplevel to repo info","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2026-04-09T13:13:35Z","receivedAt":"2026-04-09T13:13:37Z","isPatch":true,"body":"\"Jayesh Daga via GitGitGadget\" <gitgitgadget@gmail.com> writes:\n\n> From: Jayesh Daga <jayeshdaga99@gmail.com>\n>\n> repo info currently does not expose the repository's\n> working tree root, even though this information is\n> available via `repo_get_work_tree()` and\n> `git rev-parse --show-toplevel`.\n>\n> Add a new field `paths.toplevel` to expose this value.\n>\n> While doing so, document the correspondence between\n> `git rev-parse` options and `repo info` fields to make\n> it easier to identify missing or future additions.\n>\n> For bare repositories, this value is empty, consistent\n> with other non-applicable fields.\n>\n\nDon't we still have to decide how we want to support relative vs\nabsolute paths? [1]\n\nAlso seeing that you're a GSoC candidate and this is part of the project\nthat you've (and other potential contributors) applied for, our\nrecommendation is to not start working on a project before the selection\nprocess.\n\n[snip]\n\n[1]: https://lore.kernel.org/git/CA+rGoLfbzXqP1Tw+94jMmWcSGPoefMv5E_fvwriad-O5CUeKHQ@mail.gmail.com/T/#m1e2b69b6b097c42b06088349947e43831cf5988f\n"},{"id":"541273","messageId":"xmqq8qaww5y1.fsf@gitster.g","threadId":"65417","inReplyTo":"pull.2264.v3.git.git.1775714492944.gitgitgadget@gmail.com","subject":"Re: [PATCH v3] repo: add paths.toplevel to repo info","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-09T14:42:46Z","receivedAt":"2026-04-09T14:42:49Z","isPatch":true,"body":"\"Jayesh Daga via GitGitGadget\" <gitgitgadget@gmail.com> writes:\n\n> From: Jayesh Daga <jayeshdaga99@gmail.com>\n>\n> repo info currently does not expose the repository's\n> working tree root, even though this information is\n> available via `repo_get_work_tree()` and\n> `git rev-parse --show-toplevel`.\n>\n> Add a new field `paths.toplevel` to expose this value.\n>\n> While doing so, document the correspondence between\n> `git rev-parse` options and `repo info` fields to make\n> it easier to identify missing or future additions.\n>\n> For bare repositories, this value is empty, consistent\n> with other non-applicable fields.\n>\n> Signed-off-by: Jayesh Daga jayeshdaga99@gmail.com\n> ---\n\nSo \"document the correspondence\" added to the v2 iteration is still\nup there.  I expect to see such a change in the patch body.\n\n>     repo: add paths.toplevel to repo info\n>     \n>     repo info currently does not expose the repository's working tree root,\n>     even though this information is available via repo_get_work_tree().\n>     \n>     This makes it harder for scripts to retrieve the repository root through\n>     a structured interface, often requiring the use of git rev-parse\n>     --show-toplevel.\n>     \n>     Add a new field paths.toplevel to git repo info that returns the working\n>     tree root. For bare repositories, this value is empty, consistent with\n>     other non-applicable fields.\n>     \n>     This provides a consistent and script-friendly way to query repository\n>     paths without invoking additional commands.\n>     \n>     Signed-off-by: Jayesh Daga jayeshdaga99@gmail.com\n\nThis space below the three-dash is not where reiterate what you\nalready wrote in the commit log message.  Rather, this is a place to\ngive additional explanation that should not go in the commit log\nmessage, like \"the previous iteration botched X and Y which have\nbeen corrected in this version\", etc.\n\nI see this mistake often in patches from GGG users---please double\ncheck how to use that tool (I am not a GGG user, but I vaguely\nrecall that GGG duplicates what you wrote in the pull request\nmessage after the three-dashes, so perhaps you are expected to\nrewrite the pull request message every time to summarize the\ndifferences since the last iteration before you submit a new\niteration, or something?).\n\n> Range-diff vs v2:\n>\n>  1:  05e34bfe2c ! 1:  8a58b6ce03 repo: add paths.toplevel to repo info\n>      @@ Commit message\n>           For bare repositories, this value is empty, consistent\n>           with other non-applicable fields.\n>       \n>      -    Signed-off-by: Jayesh Daga [jayeshdaga99@gmail.com](mailto:jayeshdaga99@gmail.com)\n>      +    Signed-off-by: Jayesh Daga jayeshdaga99@gmail.com\n\nOK.\n\n>      -@@ builtin/repo.c: static const struct repo_info_field repo_info_field[] = {\n>      +@@ builtin/repo.c: static int get_references_format(struct repository *repo, struct strbuf *buf)\n>      + \treturn 0;\n>      + }\n>      + \n>      ++/*\n>      ++ * rev-parse --<opt>        repo info <field>\n>      ++ *\n>      ++ * is-bare-repository      layout.bare\n>      ++ * is-shallow-repository   layout.shallow\n>      ++ * show-object-format      object.format\n>      ++ * show-ref-format         references.format\n>      ++ * show-toplevel           paths.toplevel\n>      ++ *\n>      ++ * show-cdup               <missing>\n>      ++ * show-prefix             <missing>\n>      ++ *\n>      ++ * Some <missing> entries may be candidates for future\n>      ++ * implementation, while others may not be needed.\n\nIt is a surprisingly small set.  Did you do your own research, or\ndid you only copied what I gave as examples?\n\n> +static int get_paths_toplevel(struct repository *repo, struct strbuf *buf)\n> +{\n> +\tconst char *wt = repo_get_work_tree(repo);\n> +\n> +\tif (!wt)\n> +\t\treturn -1; /* match existing error style */\n\nThat is not a very helpful comment.  It sounds more like \"I do not\nunderstand why I am supposed to return -1 here upon error, but I am\njust blindly following what everybody else does\" excuse, than \"I\nreturn -1 upon an error because the caller is prepared to act on it\nand do X, which is what we want to see when repo_get_work_tree(repo)\nreturns NULL, which signals condition Y that should be reported as\nsuch\" explanation.  If the reason why returning -1 is so obvious\nthat we do not even have to say it (which I suspect is the case),\nthen future readers would appreciate if you didn't add such a\ncomment.  If the reason why this needs to return -1 (and not -2 or\n-999 or whatever) is so subtle and needs to be explained, then the\ncomment does not give even a single bit of information to help them\nunderstand why.\n\n> +\tstrbuf_addstr(buf, wt);\n> +\treturn 0;\n> +}\n\n> diff --git a/t/t1900-repo-info.sh b/t/t1900-repo-info.sh\n> index 39bb77dda0..470e06e8c2 100755\n> --- a/t/t1900-repo-info.sh\n> +++ b/t/t1900-repo-info.sh\n> @@ -155,4 +155,20 @@ test_expect_success 'git repo info -h shows only repo info usage' '\n>  \ttest_grep ! \"git repo structure\" actual\n>  '\n>  \n> +test_expect_success 'repo info paths.toplevel' '\n> +    git repo info paths.toplevel >actual &&\n> +    echo \"paths.toplevel=$(git rev-parse --show-toplevel)\" >expected &&\n\nThese seem to be SP*4 indented; one level of indent is supposed to\nbe a single tab, not 4-column.\n\nYou may have copied it from other tests, but the above is\ndone in an unusual order and I found it harder to read.\n\nWe prepare an expected output in a file called \"expect\" first, and\nthen store the output of the command we are testing in a file called\n\"actual\", and then compare \"test_cmp expect actual\", in this order.\n\nIf you deliberately misspell the command to pass \"--shaw-toplabel\",\ndoes it break this \"echo\" invocation, or will we only notice the\nbreakage/mistake when we check the output in the \"expect\" file\nagainst \n\n> +    test_cmp expected actual\n> +'\n> +\n> +test_expect_success 'repo info paths.toplevel (bare repo)' '\n> +    git init --bare bare.git &&\n> +    (\n> +\tcd bare.git &&\n> +\tgit repo info paths.toplevel >actual &&\n> +\techo \"paths.toplevel=\" >expected &&\n> +\ttest_cmp expected actual\n> +    )\n> +'\n> +\n>  test_done\n>\n> base-commit: 256554692df0685b45e60778b08802b720880c50\n"},{"id":"541274","messageId":"xmqq4ilkw5om.fsf@gitster.g","threadId":"65417","inReplyTo":"CAOLa=ZRo2qWES4XW3UuDxe1Wjew_z7PDy48qQdsjQzD=G8E2ew@mail.gmail.com","subject":"Re: [PATCH v3] repo: add paths.toplevel to repo info","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-09T14:48:25Z","receivedAt":"2026-04-09T14:48:30Z","isPatch":true,"body":"Karthik Nayak <karthik.188@gmail.com> writes:\n\n> Don't we still have to decide how we want to support relative vs\n> absolute paths? [1]\n\nI suspect more than just a few requests to this command yield\npath-valued response, so do we want an independent boolean \"if we\nare showing a path, show it in relative (yes) or absolute (no)\"\noption, or something?\n\n> Also seeing that you're a GSoC candidate and this is part of the project\n> that you've (and other potential contributors) applied for, our\n> recommendation is to not start working on a project before the selection\n> process.\n\nPerhaps I should refrain from commenting on these patches to\ndiscourage the authors if that is the case.  I am not raising an\nobjection, but do you have a pointer to the rationale behind the\nrecommendation?\n"},{"id":"541276","messageId":"CAOLa=ZSwVbqWCo5PoUtZRx-bW-96tymL6TQp23BrRRrOveFrFg@mail.gmail.com","threadId":"65417","inReplyTo":"xmqq4ilkw5om.fsf@gitster.g","subject":"Re: [PATCH v3] repo: add paths.toplevel to repo info","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2026-04-09T16:01:24Z","receivedAt":"2026-04-09T16:01:49Z","isPatch":true,"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Karthik Nayak <karthik.188@gmail.com> writes:\n>\n>> Don't we still have to decide how we want to support relative vs\n>> absolute paths? [1]\n>\n> I suspect more than just a few requests to this command yield\n> path-valued response, so do we want an independent boolean \"if we\n> are showing a path, show it in relative (yes) or absolute (no)\"\n> option, or something?\n>\n\nI think there was some ideas around this:\n\n  - Have a default mode and a way to swap it. Perhaps a boolean config\n    on the command level\n  - Output both the relative and absolute paths. So we'd have\n    paths.toplevel.absolute\n    paths.toplevel.relative\n    or something like that.\n\nEither ways, I think we should finalize the decision first, that way we\ndon't have to have this discussion with each path-valued option.\n\n>> Also seeing that you're a GSoC candidate and this is part of the project\n>> that you've (and other potential contributors) applied for, our\n>> recommendation is to not start working on a project before the selection\n>> process.\n>\n> Perhaps I should refrain from commenting on these patches to\n> discourage the authors if that is the case.  I am not raising an\n> objection, but do you have a pointer to the rationale behind the\n> recommendation?\n\nOfficially the GSoC rules [1] only say:\n\n  Any work done on the Project prior to acceptance of the Project Proposal\n  will not be considered for Evaluations.\n\nSo there is no rule stopping a contributor from making such changes, and\nultimately, open source projects benefit from contributions regardless\nof the contributor's application status.\n\nHowever it gets confusing for other contributors who have proposals for\nthe same topic, since they expect a certain status quo and a moving goal\npost makes it a lot harder.\n\n[1]: https://summerofcode.withgoogle.com/rules\n"}]}