From: Junio C Hamano <gitster@pobox.com>
To: Shawn Pearce <spearce@spearce.org>
Cc: git@vger.kernel.org, Dennis Kaarsemaker <dennis@kaarsemaker.net>
Subject: Re: [PATCH] fetch-pack: don't resend known-common refs in find_common
Date: Tue, 21 Oct 2014 10:56:26 -0700 [thread overview]
Message-ID: <xmqqd29l1f3p.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20141021144838.GA11589@seahawk> (Dennis Kaarsemaker's message of "Tue, 21 Oct 2014 16:49:07 +0200")
Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:
> By not clearing the request buffer in stateless-rpc mode, fetch-pack
> would keep sending already known-common commits, leading to ever bigger
> http requests, eventually getting too large for git-http-backend to
> handle properly without filling up the pipe buffer in inflate_request.
> ---
> I'm still not quite sure whether this is the right thing to do, but make
> test still passes :) The new testcase demonstrates the problem, when
> running t5551 with EXPENSIVE, this test will hang without the patch to
> fetch-pack.c and succeed otherwise.
IIUC, because "stateless" is just that, i.e. the server-end does not
keep track of what is already known, not telling what is known to be
common in each request would fundamentally break the protocol. Am I
mistaken?
> fetch-pack.c | 1 -
> t/t5551-http-fetch-smart.sh | 32 ++++++++++++++++++++++++++++++++
> 2 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/fetch-pack.c b/fetch-pack.c
> index 655ee64..258245c 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -410,7 +410,6 @@ static int find_common(struct fetch_pack_args *args,
> */
> const char *hex = sha1_to_hex(result_sha1);
> packet_buf_write(&req_buf, "have %s\n", hex);
> - state_len = req_buf.len;
> }
> mark_common(commit, 0, 1);
> retval = 0;
> diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
> index 6cbc12d..2aac237 100755
> --- a/t/t5551-http-fetch-smart.sh
> +++ b/t/t5551-http-fetch-smart.sh
> @@ -245,5 +245,37 @@ test_expect_success EXPENSIVE 'clone the 50,000 tag repo to check OS command lin
> )
> '
>
> +test_expect_success EXPENSIVE 'create 50,000 more tags' '
> + (
> + cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
> + for i in `test_seq 50001 100000`
> + do
> + echo "commit refs/heads/too-many-refs-again"
> + echo "mark :$i"
> + echo "committer git <git@example.com> $i +0000"
> + echo "data 0"
> + echo "M 644 inline bla.txt"
> + echo "data 4"
> + echo "bla"
> + # make every commit dangling by always
> + # rewinding the branch after each commit
> + echo "reset refs/heads/too-many-refs-again"
> + echo "from :50001"
> + done | git fast-import --export-marks=marks &&
> +
> + # now assign tags to all the dangling commits we created above
> + tag=$(perl -e "print \"bla\" x 30") &&
> + sed -e "s|^:\([^ ]*\) \(.*\)$|\2 refs/tags/$tag-\1|" <marks >>packed-refs
> + )
> +'
> +
> +test_expect_success EXPENSIVE 'fetch the new tags' '
> + (
> + cd too-many-refs &&
> + git fetch --tags &&
> + test $(git for-each-ref refs/tags | wc -l) = 100000
> + )
> +'
> +
> stop_httpd
> test_done
next prev parent reply other threads:[~2014-10-21 17:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-20 14:29 git fetch (http) hanging/failing on one specific repository, http only Dennis Kaarsemaker
2014-10-21 9:48 ` Bug in fetch-pack causing ever-growing http requests. (Was: git fetch (http) hanging/failing on one specific repository, http only) Dennis Kaarsemaker
2014-10-21 14:49 ` [PATCH] fetch-pack: don't resend known-common refs in find_common Dennis Kaarsemaker
2014-10-21 17:56 ` Junio C Hamano [this message]
2014-10-22 7:41 ` Dennis Kaarsemaker
2014-10-22 10:07 ` Duy Nguyen
2014-10-26 15:42 ` Dennis Kaarsemaker
2014-10-22 17:11 ` Junio C Hamano
2014-10-26 15:39 ` Dennis Kaarsemaker
2014-12-06 0:48 ` Shawn Pearce
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=xmqqd29l1f3p.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=dennis@kaarsemaker.net \
--cc=git@vger.kernel.org \
--cc=spearce@spearce.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.