Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Do not call git-rev-list from git-fetch-pack
Date: Fri, 21 Oct 2005 10:11:00 -0700	[thread overview]
Message-ID: <7vwtk6vlqz.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0510211111440.4950@wbgn013.biozentrum.uni-wuerzburg.de> (Johannes Schindelin's message of "Fri, 21 Oct 2005 11:35:21 +0200 (CEST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Note that the best thing would probably be to add a binary search to that, 
> and *not* stop at the first ack'ed rev, but rather count them, and stop at 
> MAX_HAS.

Another alternative.

We send "haves" in order, without 2^n skipping nor binary search
backtrack.  Instead, add a logic in upload-pack to see if a
newly arrived "have" is a direct child of anything that we have
already heard about, and mark to ignore them.  We need to add
that MAX_HAS counting to fetch-pack side for this to work.

This is not even compile tested, but just to outline the idea.

(... now off to day-job ...)

---

diff --git a/upload-pack.c b/upload-pack.c
index 8a41caf..d98a28e 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -3,9 +3,11 @@
 #include "pkt-line.h"
 #include "tag.h"
 #include "object.h"
+#include "commit.h"
 
 static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
 
+#define THEY_HAVE (1U << 0)
 #define MAX_HAS (16)
 #define MAX_NEEDS (256)
 static int nr_has = 0, nr_needs = 0;
@@ -92,6 +94,20 @@ static int got_sha1(char *hex, unsigned 
 		return 0;
 	nr = nr_has;
 	if (nr < MAX_HAS) {
+		struct object *o = lookup_object(sha1);
+		if (!o || (o->parsed || !parse_object(sha1)))
+			die("oops");
+		if (o->type == commit_type) {
+			struct commit_list *parents;
+			if (o->flags & THEY_HAVE)
+				return 0;
+			o->flags |= THEY_HAVE;
+			for (parents = ((struct commit*)o)->parents;
+			     parents;
+			     parents = parents->next) {
+				parents->item->object.flags |= THEY_HAVE;
+			}
+		}
 		memcpy(has_sha1[nr], sha1, 20);
 		nr_has = nr+1;
 	}
@@ -104,6 +120,9 @@ static int get_common_commits(void)
 	unsigned char sha1[20];
 	int len;
 
+	track_object_refs = 0;
+	save_commit_buffer = 0;
+
 	for(;;) {
 		len = packet_read_line(0, line, sizeof(line));
 		reset_timeout();

  reply	other threads:[~2005-10-21 17:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-21  2:15 [PATCH] Do not call git-rev-list from git-fetch-pack Johannes Schindelin
2005-10-21  8:51 ` Junio C Hamano
2005-10-21  9:35   ` Johannes Schindelin
2005-10-21 17:11     ` Junio C Hamano [this message]
2005-10-21 19:44       ` Johannes Schindelin
2005-10-21 21:32         ` Junio C Hamano
2005-10-22  0:35           ` Johannes Schindelin
2005-10-21 20:25     ` Daniel Barkalow
2005-10-21 21:08       ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vwtk6vlqz.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox