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
Patrick Steinhardt <ps@pks.im>
Date
Feb 7, 2025, 06:16 UTC
Message-ID
<Z6WlMvasi64N3dQQ@pks.im>
In-Reply-To
<Z6TFZGNjs3Xfkh9x@ArchLinux>
On Thu, Feb 06, 2025 at 10:21:24PM +0800, shejialuo wrote:
Show 26 quoted lines
> On Thu, Feb 06, 2025 at 08:57:57AM +0100, Patrick Steinhardt wrote:
> > 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?
It allows patterns like this:
    if (stat(&st, repo_common_path_replace(...)) ||
        unlink(&st, repo_common_path_replace(...)))
            ...

So the reason is not that I want to follow a common pattern, the reason is that it's useful to some callers.

> 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.
Yeah, that's fair. I'll adapt the commit message to explain this better.
Show 18 quoted lines
> > diff --git a/path.h b/path.h
> > index 5f6c85e5f8..3c75495e1a 100644
> > --- a/path.h
> > +++ b/path.h
> > @@ -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?

We can't, it's still used to implement `git_common_path()` in the header. We'll remove it in a subsequent commit.

Patrick
Previous: shejialuoNext: Patrick Steinhardt
Message 6 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.