Re: [PATCH 6/8] fetch: deduplicate logic to print remote URL

2 messages, 2 authors, 2023-03-16 · open the first message on its own page

Re: [PATCH 6/8] fetch: deduplicate logic to print remote URL

From: Junio C Hamano <hidden>
Date: 2023-03-15 23:02:23

Patrick Steinhardt [off-list ref] writes:
When fetching from a remote, we not only print the actual references
that have changed, but will also print the URL from which we have
fetched them to standard output. The logic to handle this is duplicated
across two different callsites with some non-trivial logic to compute
the anonymized URL. Furthermore, we're using global state to track
whether we have already shown the URL to the user or not.
If we are certain that store_updated_refs() is called only once for
the entire process, then storing the preprocessed url in the display
state and passing it around does sound like a good optimization and
clean-up.  What do we do when fetching from multiple remotes?
+	display->url_len = strlen(display->url);
+	for (i = display->url_len - 1; display->url[i] == '/' && 0 <= i; i--)
+		;
+	display->url_len = i + 1;
This loop is inherited from the original, but we may want to use
strrchr() or rindex() as a post clean-up after this series settles.

Re: [PATCH 6/8] fetch: deduplicate logic to print remote URL

From: Patrick Steinhardt <hidden>
Date: 2023-03-16 15:06:22

On Wed, Mar 15, 2023 at 04:02:18PM -0700, Junio C Hamano wrote:
Patrick Steinhardt [off-list ref] writes:
quoted
When fetching from a remote, we not only print the actual references
that have changed, but will also print the URL from which we have
fetched them to standard output. The logic to handle this is duplicated
across two different callsites with some non-trivial logic to compute
the anonymized URL. Furthermore, we're using global state to track
whether we have already shown the URL to the user or not.
If we are certain that store_updated_refs() is called only once for
the entire process, then storing the preprocessed url in the display
state and passing it around does sound like a good optimization and
clean-up.  What do we do when fetching from multiple remotes?
We execute separate git-fetch(1) processes when fetching from multiple
remotes or when fetching submodules, so we should be fine here.
quoted
+	display->url_len = strlen(display->url);
+	for (i = display->url_len - 1; display->url[i] == '/' && 0 <= i; i--)
+		;
+	display->url_len = i + 1;
This loop is inherited from the original, but we may want to use
strrchr() or rindex() as a post clean-up after this series settles.
Yeah, that'd make sense.

Patrick
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help