Thanks for digging up the history and context for these functions. I agree that refactoring these functions right now is not worth it and can be saved for when there would be new callers to them. On Wed, May 3, 2023 at 9:34 AM Jeff King <peff@xxxxxxxx> wrote: > > On Wed, May 03, 2023 at 12:28:58PM -0400, Jeff King wrote: > > > I think the main reason we do not have other callers is that urlmatch.c > > implements its own percent-encoding code, and that's where we do most of > > our URL handling. It does make me wonder if credential-store could > > simply switch to using that, but that is probably out of scope for your > > series. > > Poking at it a bit, I think the answer is "not easily". credential-store > has broken-out elements of a URL, and wants to turn them back into one. > And urlmatch.c's url_normalize() always takes a URL string as input. > Even though it finds the broken-out fields as part of its work, the > parsing and reconstruction of the URL are inter-mingled in a complex > way (i.e., it's not just "parse it, then turn the fields back into a > normalized string). > > I'm sure it could be refactored, but it's probably not worth it (and > again, this tangent is somewhat orthogonal to your series, except that > it would make these is_rfc3986 functions go away entirely). > > -Peff
