Re: [GSoC][PATCH] remote: relocate valid_remote_name
From: Junio C Hamano <hidden>
Date: 2025-02-04 14:38:10
Meet Soni [off-list ref] writes:
quoted hunk
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 <redacted> --- 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/ (local) 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.