Meet Soni <meetsoni3017@xxxxxxxxx> 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@xxxxxxxxx> > --- > 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.
