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

Re: [PATCH 01/16] path: refactor `repo_common_path()` family of functions

From
shejialuo <shejialuo@gmail.com>
Date
Feb 6, 2025, 14:21 UTC
Message-ID
<Z6TFZGNjs3Xfkh9x@ArchLinux>
In-Reply-To
<20250206-b4-pks-path-drop-the-repository-v1-1-4e77f0313206@pks.im>
On Thu, Feb 06, 2025 at 08:57:57AM +0100, Patrick Steinhardt wrote:
Show 19 quoted lines
> The functions provided by the "path" subsystem to derive repository
> paths for the commondir, gitdir, worktrees and submodules are quite
> inconsistent. Some functions have a `strbuf_` prefix, others have
> different return values, some don't provide a variant working on top of
> `strbuf`s.
> 
> We're thus about to refactor all of these family of functions so that
> they follow a common pattern:
> 
>   - `repo_*_path()` returns an allocated string.
> 
>   - `repo_*_path_append()` appends the path to the caller-provided
>     buffer while returning a constant pointer to the buffer. This
>     clarifies whether the buffer is being appended to or rewritten,
>     which otherwise wasn't immediately obvious.
> 
>   - `repo_*_path_replace()` replaces contents of the buffer with the
>     computed path, again returning a pointer to the buffer contents.
> 

I want to ask a design question about this. Why do we need to return the raw pointer to the `struct strbuf` for the last two cases? I somehow understand why you want to do this. You want to follow a common pattern for those three functions. But I wonder should we let the caller to decide whether they want to use the raw pointer?

And in this patch, the return value of the last two cases has never been used. Until I read the next patch, I have seen the usage of the return value thus I could understand your motivation.

Show 48 quoted lines
> diff --git a/path.h b/path.h
> index 5f6c85e5f8..3c75495e1a 100644
> --- a/path.h
> +++ b/path.h
> @@ -25,22 +25,20 @@ char *mkpathdup(const char *fmt, ...)
>  	__attribute__((format (printf, 1, 2)));
>  
>  /*
> - * The `strbuf_git_common_path` family of functions will construct a path into a
> + * The `repo_common_path` family of functions will construct a path into a
>   * repository's common git directory, which is shared by all worktrees.
>   */
> -
> -/*
> - * Constructs a path into the common git directory of repository `repo` and
> - * append it in the provided buffer `sb`.
> - */
> -void strbuf_git_common_path(struct strbuf *sb,
> -			    const struct repository *repo,
> -			    const char *fmt, ...)
> +char *repo_common_path(const struct repository *repo,
> +		       const char *fmt, ...)
> +	__attribute__((format (printf, 2, 3)));
> +const char *repo_common_path_append(const struct repository *repo,
> +				    struct strbuf *sb,
> +				    const char *fmt, ...)
> +	__attribute__((format (printf, 3, 4)));
> +const char *repo_common_path_replace(const struct repository *repo,
> +				     struct strbuf *sb,
> +				     const char *fmt, ...)
>  	__attribute__((format (printf, 3, 4)));
> -void repo_common_pathv(const struct repository *repo,
> -		       struct strbuf *buf,
> -		       const char *fmt,
> -		       va_list args);
>  
>  /*
>   * The `repo_git_path` family of functions will construct a path into a repository's
> @@ -243,6 +241,12 @@ struct strbuf *get_pathname(void);
>  #  include "strbuf.h"
>  #  include "repository.h"
>  
> +/* Internal implementation detail that should not be used. */
> +void repo_common_pathv(const struct repository *repo,
> +		       struct strbuf *buf,
> +		       const char *fmt,
> +		       va_list args);
> +

If we decide to make this as internal implementation, why we don't just delete this declaration in the header file? Do I miss out something here?

Thanks, Jialuo

Previous: Patrick SteinhardtNext: Patrick Steinhardt
Message 5 of 36 in “path: remove dependency on `the_repository`”
  1. 00/16 path: remove dependency on `the_repository`Patrick Steinhardt, Feb 6, 2025
  2. 01/16 path: refactor `repo_common_path()` family of functionsPatrick Steinhardt, Feb 6, 2025
  3. Karthik NayakFeb 6, 2025
  4. Patrick SteinhardtFeb 7, 2025
  5. shejialuoFeb 6, 2025
  6. Patrick SteinhardtFeb 7, 2025
  7. 02/16 path: refactor `repo_git_path()` family of functionsPatrick Steinhardt, Feb 6, 2025
  8. Karthik NayakFeb 6, 2025
  9. Patrick SteinhardtFeb 7, 2025
  10. 03/16 path: refactor `repo_worktree_path()` family of functionsPatrick Steinhardt, Feb 6, 2025
  11. 04/16 submodule: refactor `submodule_to_gitdir()` to accept a repoPatrick Steinhardt, Feb 6, 2025
  12. 05/16 path: refactor `repo_submodule_path()` family of functionsPatrick Steinhardt, Feb 6, 2025
  13. Karthik NayakFeb 6, 2025
  14. Patrick SteinhardtFeb 7, 2025
  15. Karthik NayakFeb 7, 2025
  16. shejialuoFeb 6, 2025
  17. 06/16 path: drop unused `strbuf_git_path()` functionPatrick Steinhardt, Feb 6, 2025
  18. 07/16 path: drop `git_pathdup()` in favor of `repo_git_path()`Patrick Steinhardt, Feb 6, 2025
  19. 08/16 path: drop `git_path_buf()` in favor of `repo_git_path_replace()`Patrick Steinhardt, Feb 6, 2025
  20. 09/16 worktree: return allocated string from `get_worktree_git_dir()`Patrick Steinhardt, Feb 6, 2025
  21. Karthik NayakFeb 7, 2025
  22. Patrick SteinhardtFeb 7, 2025
  23. 10/16 path: drop `git_common_path()` in favor of `repo_common_path()`Patrick Steinhardt, Feb 6, 2025
  24. shejialuoFeb 6, 2025
  25. Patrick SteinhardtFeb 7, 2025
  26. 11/16 rerere: let `rerere_path()` write paths into a caller-provided bufferPatrick Steinhardt, Feb 6, 2025
  27. 12/16 path: drop `git_path()` in favor of `repo_git_path()`Patrick Steinhardt, Feb 6, 2025
  28. shejialuoFeb 6, 2025
  29. Patrick SteinhardtFeb 7, 2025
  30. 13/16 repo-settings: introduce function to clear structPatrick Steinhardt, Feb 6, 2025
  31. 14/16 environment: move access to "core.hooksPath" into repo settingsPatrick Steinhardt, Feb 6, 2025
  32. 15/16 environment: move access to "core.sharedRepository" into repo settingsPatrick Steinhardt, Feb 6, 2025
  33. 16/16 path: adjust last remaining users of `the_repository`Patrick Steinhardt, Feb 6, 2025
  34. shejialuoFeb 6, 2025
  35. Patrick SteinhardtFeb 7, 2025
  36. Karthik NayakFeb 7, 2025

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.