Re: [GSoC][PATCH] remote: relocate valid_remote_name

[Junio C Hamano <gitster@pobox.com>]

Meet Soni <meetsoni3017@gmail.com> writes:

> Move the `valid_remote_name()` function from `refspec.h` to `remote.h` to
> better align with the separation of concerns.
>
> Signed-off-by: Meet Soni <meetsoni3017@gmail.com>
> ---
> Junio mentioned in [1], the `valid_remote_name` function belongs in remote
> header. This patch addresses that.
>
> [1]: https://lore.kernel.org/git/xmqqikq0ruuk.fsf@gitster.g/
>  refspec.c | 10 ----------
>  refspec.h |  1 -
>  remote.c  | 10 ++++++++++
>  remote.h  |  2 ++
>  4 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/refspec.c b/refspec.c
> index 6d86e04442..83ec7d7e62 100644
> --- a/refspec.c
> +++ b/refspec.c
> @@ -236,16 +236,6 @@ int valid_fetch_refspec(const char *fetch_refspec_str)
>  	return ret;
>  }
>  
> -int valid_remote_name(const char *name)
> -{
> -	int result;
> -	struct strbuf refspec = STRBUF_INIT;
> -	strbuf_addf(&refspec, "refs/heads/test:refs/remotes/%s/test", name);
> -	result = valid_fetch_refspec(refspec.buf);
> -	strbuf_release(&refspec);
> -	return result;
> -}
> -
>  void refspec_ref_prefixes(const struct refspec *rs,
>  			  struct strvec *ref_prefixes)
>  {

This cuts both ways, though.  As valid_remote_name() is the only
external caller of valid_fetch_refspec(), without this patch, the
former function can become a file-scope static in refspec.c, but
with this patch in place, it has to stay to be public.

I do see how valid_remote_name() would be useful as a public
function, but I do not know how useful valid_fetch_refspec() is, as
a part of external refspec API.  There is no reason other than that
it gives us a handy way to implement valid_remote_name() for it to
exist.

So I dunno.

Thanks.