git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Tian Yuchen <a3205153416@gmail.com>
Date
Mar 3, 2026, 09:28 UTC
Message-ID
<46c60949-87f1-426a-aeb9-706e97fd8e8a@gmail.com>
In-Reply-To
<CA+rGoLc+ULYUZaDCdAHxuL8T-qyjJKTRJfSe6Muhb7c6d12e_w@mail.gmail.com>
Hi JAYATHEERTH,
Thanks for the reply.
> To clarify my earlier comment: I wasn't arguing against ref-filter.
> In fact, I’m more inclined toward using the best tool for the job.
> My earlier point was mainly about behavioral similarity and how both
> belong to the same camp even though they might seem different.
 > I just meant both the ideas are in the same camp just unrealized.

That's exactly right. I was just reminding that there's a ready-made solution available that seems to work very well. Wouldn't reinventing something that already exists, with only minor differences, cause confusion? (´;ω;`)

Show 45 quoted lines
> something like this:
> 
> 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.toplevel", get_path_toplevel },
> };
> 
> This array contains all the keys
> You do not need to hardcode path.absolute.toplevel,
> path.relative.toplevel, etc., in the array...
> 
> Instead,
> 
> If the user asks for path.absolute.toplevel:
> You detect the absolute. middle part. strip it out to find the base
> key path.toplevel.
> You find path.toplevel in the aray, the array works with default
> values when entered --all
> 
> /*
>   * Helper to parse the key variant.
>   * Takes "path.absolute.git-dir" -> returns "path.git-dir" and sets
> opts->format.
>   */
> static char *normalize_key(const char *raw_key, struct repo_info_opts *opts)
> {
>      const char *suffix;
> 
>      /* Check for "path.absolute." prefix */
>      if (skip_prefix(raw_key, "path.absolute.", &suffix)) {
>          opts->path_format = PATH_FORMAT_ABSOLUTE;
>          return xstrfmt("path.%s", suffix);
>      }
> 
>      /* Check for "path.relative." prefix */
>      if (skip_prefix(raw_key, "path.relative.", &suffix)) {
>          opts->path_format = PATH_FORMAT_RELATIVE;
>          return xstrfmt("path.%s", suffix);
>      }
> 
>      /* No variant found, return raw key as-is */
>      return xstrdup(raw_key);
> }

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

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

Previous: JAYATHEERTH KNext: JAYATHEERTH K
Message 24 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. Tian YuchenMar 1, 2026
  7. Lucas Seiki OshiroMar 1, 2026
  8. Tian YuchenMar 2, 2026
  9. JAYATHEERTH KMar 1, 2026
  10. Ayush JhaMar 1, 2026
  11. JAYATHEERTH KMar 1, 2026
  12. Lucas Seiki OshiroMar 1, 2026
  13. Ayush JhaMar 3, 2026
  14. Lucas Seiki OshiroMar 1, 2026
  15. Phillip WoodMar 1, 2026
  16. Lucas Seiki OshiroMar 1, 2026
  17. brian m. carlsonMar 1, 2026
  18. Junio C HamanoMar 2, 2026
  19. Tian YuchenMar 2, 2026
  20. Junio C HamanoMar 2, 2026
  21. JAYATHEERTH KMar 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.