maybe breakage with latest git-pull and http protocol

4 messages, 3 authors, 2016-06-15 · open the first message on its own page

maybe breakage with latest git-pull and http protocol

From: Randal L. Schwartz <hidden>
Date: 2016-06-15 22:42:08

I updated git to d06b689a933f6d2130f8afdf1ac0ddb83eeb59ab,
then compiled and installed.

When I went to "git-pull" on my cogito archive (which I had edited
to use HTTP instead of RSYNC), I got into trouble.  Unfortunately,
I changed it to rsync to force cogito into a sane state before
I realized that this would be a good bug report. :)

This is perhaps just a heads-up that the recent git-pull might be
broken with respect to http updates.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: maybe breakage with latest git-pull and http protocol

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:08

merlyn@stonehenge.com (Randal L. Schwartz) writes:
I updated git to d06b689a933f6d2130f8afdf1ac0ddb83eeb59ab,
then compiled and installed.

When I went to "git-pull" on my cogito archive (which I had edited
to use HTTP instead of RSYNC), I got into trouble.  Unfortunately,
I changed it to rsync to force cogito into a sane state before
I realized that this would be a good bug report. :)
Indeed I wish we could see the set of refs you had and output
from fsck-objects before the failed git-pull and after.

One thing I am aware of is that cogito repository at kernel.org
is not set up to be HTTP friendly -- it lacks info/refs file
git-clone uses for discovery of the available refs.

Cogito's clone/fetch over HTTP uses recursive wget for
discovery, and I presume that is one of the reasons nobody
noticed this.  Another reason may probably be that more people
use rsync transport.

Re: maybe breakage with latest git-pull and http protocol

From: Randal L. Schwartz <hidden>
Date: 2016-06-15 22:42:09

quoted
quoted
quoted
quoted
"Randal" == Randal L Schwartz [off-list ref] writes:
Randal> I updated git to d06b689a933f6d2130f8afdf1ac0ddb83eeb59ab,
Randal> then compiled and installed.

Randal> When I went to "git-pull" on my cogito archive (which I had edited
Randal> to use HTTP instead of RSYNC), I got into trouble.  Unfortunately,
Randal> I changed it to rsync to force cogito into a sane state before
Randal> I realized that this would be a good bug report. :)

Randal> This is perhaps just a heads-up that the recent git-pull might be
Randal> broken with respect to http updates.

Even after updating git this morning, git-pull still seems to be broken
with respect to http://www.kernel.org/.
Is http pulling broken for good now?  Or is someone looking at this?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: maybe breakage with latest git-pull and http protocol

From: Nick Hengeveld <hidden>
Date: 2016-06-15 22:42:09

Can you try using the following patch?  This cleans up curl handles for
active request slots that are no longer in use.  If all other prefetched
requests finish while a large transfer is happening, the active slots
currently keep open connections to the server and I'm guessing that
perhaps by the time additional objects are prefetched the server has
timed out some of those keepalive connections.


---

 http-fetch.c |   26 ++++++++++++++++++++------
 1 files changed, 20 insertions(+), 6 deletions(-)

applies-to: ce9a5a0fdd52a29e370d849a132b4509c844aca1
04b4353279eaceb7e7c3d73a9565b219aa7a10a9
diff --git a/http-fetch.c b/http-fetch.c
index a7dc2cc..d26fae8 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -291,11 +291,7 @@ static struct active_request_slot *get_a
 	}
 	if (slot == NULL) {
 		newslot = xmalloc(sizeof(*newslot));
-#ifdef NO_CURL_EASY_DUPHANDLE
-		newslot->curl = get_curl_handle();
-#else
-		newslot->curl = curl_easy_duphandle(curl_default);
-#endif
+		newslot->curl = NULL;
 		newslot->in_use = 0;
 		newslot->next = NULL;
 
@@ -311,6 +307,14 @@ static struct active_request_slot *get_a
 		slot = newslot;
 	}
 
+	if (slot->curl == NULL) {
+#ifdef NO_CURL_EASY_DUPHANDLE
+		slot->curl = get_curl_handle();
+#else
+		slot->curl = curl_easy_duphandle(curl_default);
+#endif
+	}
+
 	active_requests++;
 	slot->in_use = 1;
 	slot->done = 0;
@@ -612,6 +616,7 @@ void process_curl_messages(void)
 void process_request_queue(void)
 {
 	struct transfer_request *request = request_queue_head;
+	struct active_request_slot *slot = active_queue_head;
 	int num_transfers;
 
 	while (active_requests < max_requests && request != NULL) {
@@ -624,6 +629,14 @@ void process_request_queue(void)
 		}
 		request = request->next;
 	}
+
+	while (slot != NULL) {
+		if (!slot->in_use && slot->curl != NULL) {
+			curl_easy_cleanup(slot->curl);
+			slot->curl = NULL;
+		}
+		slot = slot->next;
+	}				
 }
 #endif
 
@@ -1297,7 +1310,8 @@ int main(int argc, char **argv)
 #endif
 	slot = active_queue_head;
 	while (slot != NULL) {
-		curl_easy_cleanup(slot->curl);
+		if (slot->curl != NULL)
+			curl_easy_cleanup(slot->curl);
 		slot = slot->next;
 	}
 #ifdef USE_CURL_MULTI
---
0.99.8.GIT

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help