git/list[1] front-page[2] threads[3] people[4] search[5] about
wed 2026-10-07 17:28 UTC

Re: [PATCH 0/4] repo: add support for path-related fields

From
JAYATHEERTH K <jayatheerthkulkarni2005@gmail.com>
Date
Mar 3, 2026, 10:31 UTC
Message-ID
<CA+rGoLchSjQHn_jmHVjyOHUsYXLtmR+oOYKJc=c-ZNfpJ=S44Q@mail.gmail.com>
In-Reply-To
<46c60949-87f1-426a-aeb9-706e97fd8e8a@gmail.com>
Show 19 quoted lines
>
> I see. What you've written matches what you described — it essentially
> replicates the functionality of ref-filter.c. While I understand this is
> just a simple code implementation demo:
>
>  >          opts->path_format = PATH_FORMAT_ABSOLUTE;
>
> This implementation appears unable to support input like 'git repo-info
> --keys=path.absolute.toplevel,path.relative.gitdir', meaning it cannot
> handle multiple paths output from a single call as previously mentioned
> by Brain. The 'opts' here should be a global shared state, right?
>
> I think it's better for the parser to allocate a separate memory for
> each arg it encounters. But then we'd be back to implementing something
> like struct used_atom, hahaha (ゝ∀・)
>
> Thank you again for your email.
>
> Yuchen

We create a fresh local_opts copy from the global_opts defaults for every single key:

for (int i = 0; i < argc; i++) {
    struct repo_info_opts local_opts = global_opts; /* Fresh reset */
    char *base_key = normalize_key(argv[i], &local_opts);
    /* ... find_field and get_value logic ... */
}

Since local_opts is local to the loop iteration, path.absolute.toplevel only modifies the state for that specific turn. When the loop moves to path.relative.gitdir, it gets a brand-new local_opts and starts over. It handles mixed formats in a single call perfectly, without any persistent _pollution_ or the need for complex heap allocations.

>
> (I feel like we've been on this topic for too long. If you don't want to
> reply, you don't have to :-)
>

I agree we've covered a lot of ground here, so I'll leave it at that. Thanks for the great discussion ;)

Regards, Jayatheerth

Previous: Tian YuchenNext: Lucas Seiki Oshiro
Message 25 of 26 in “repo: add support for path-related fields”
  1. 0/4 repo: add support for path-related fieldsLucas Seiki Oshiro, Feb 28, 2026
  2. 1/4 rev-parse: prepend `path_` to path-related enumsLucas Seiki Oshiro, Feb 28, 2026
  3. 2/4 path: add new function strbuf_add_pathLucas Seiki Oshiro, Feb 28, 2026
  4. 3/4 repo: add the --format-path flagLucas Seiki Oshiro, Feb 28, 2026
  5. 4/4 repo: add the field path.toplevelLucas Seiki Oshiro, Feb 28, 2026
  6. JAYATHEERTH KMar 1, 2026
  7. Tian YuchenMar 1, 2026
  8. Ayush JhaMar 1, 2026
  9. JAYATHEERTH KMar 1, 2026
  10. Phillip WoodMar 1, 2026
  11. Lucas Seiki OshiroMar 1, 2026
  12. Lucas Seiki OshiroMar 1, 2026
  13. Lucas Seiki OshiroMar 1, 2026
  14. Lucas Seiki OshiroMar 1, 2026
  15. brian m. carlsonMar 1, 2026
  16. Tian YuchenMar 2, 2026
  17. Junio C HamanoMar 2, 2026
  18. Tian YuchenMar 2, 2026
  19. Junio C HamanoMar 2, 2026
  20. JAYATHEERTH KMar 3, 2026
  21. Ayush JhaMar 3, 2026
  22. Tian YuchenMar 3, 2026
  23. JAYATHEERTH KMar 3, 2026
  24. Tian YuchenMar 3, 2026
  25. JAYATHEERTH KMar 3, 2026
  26. Lucas Seiki OshiroMar 8, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.