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();
next prev parent 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