Re: [PATCH 02/20] path: expose `do_git_common_path()` as `strbuf_git_common_pathv()`

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24/08/07 08:56AM, Patrick Steinhardt wrote:
> With the same reasoning as the preceding commit, expose the function
> `do_git_common_path()` as `strbuf_git_common_pathv()`.
> 
> Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
> ---
>  path.c | 22 +++++++++++-----------
>  path.h |  5 ++++-
>  2 files changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/path.c b/path.c
> index 71f1cb4dfb..bff98b255e 100644
> --- a/path.c
> +++ b/path.c
> @@ -617,16 +617,16 @@ int strbuf_git_path_submodule(struct strbuf *buf, const char *path,
>  	return err;
>  }
>  
> -static void do_git_common_path(const struct repository *repo,
> -			       struct strbuf *buf,
> -			       const char *fmt,
> -			       va_list args)
> +void strbuf_git_common_pathv(struct strbuf *sb,
> +			     const struct repository *repo,
> +			     const char *fmt,
> +			     va_list args)

Here we reorder the arguments to make `strbuf` first. I assume we are do
this to align with the preexisting `strbuf_git_common_path()` and use
the "strbuf_" prefix in the function name.

In the previous commit we used the "repo_" prefix for
`repo_git_pathv()`. Would it make sense to be consistent here? All these
functions are operating on the provided buffer, but for a given
repository. Not sure what would be most appropriate here.

>  {
> -	strbuf_addstr(buf, repo->commondir);
> -	if (buf->len && !is_dir_sep(buf->buf[buf->len - 1]))
> -		strbuf_addch(buf, '/');
> -	strbuf_vaddf(buf, fmt, args);
> -	strbuf_cleanup_path(buf);
> +	strbuf_addstr(sb, repo->commondir);
> +	if (sb->len && !is_dir_sep(sb->buf[sb->len - 1]))
> +		strbuf_addch(sb, '/');
> +	strbuf_vaddf(sb, fmt, args);
> +	strbuf_cleanup_path(sb);
>  }




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux