From: Derrick Stolee <stolee@gmail.com>
To: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>
Cc: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, jonathantanmy@google.com, me@ttaylorr.com,
Derrick Stolee <dstolee@microsoft.com>,
git@jeffhostetler.com
Subject: Re: [PATCH] connected.c: reprepare packs for corner cases
Date: Thu, 12 Mar 2020 20:54:34 -0400 [thread overview]
Message-ID: <7378a863-7e2a-455e-4635-e07938ef3381@gmail.com> (raw)
In-Reply-To: <20200312212613.GB872402@coredump.intra.peff.net>
On 3/12/2020 5:26 PM, Jeff King wrote:
> On Thu, Mar 12, 2020 at 05:16:38PM -0400, Jeff King wrote:
>
>> There we see that same reprepare happen in 882839, which is the child
>> fetch-pack. The parent fetch probably needs to reprepare itself after
>> fetch-pack completes.
I agree with you and Junio that where I put the reprepare was non-
optimal. The initial reason to put it there was that I found where
the error was happening, and thought that placing the reprepare there
was the best way to prevent this error from popping up in another case.
The result of a fetch failing and saying the remote did something wrong
is quite alarming, and I wanted to avoid that from happening again in
the future from some other path.
But you're right, it's better to be as correct as possible.
> Actually, it's not fetch which is running fetch-pack, but rather the
> remote helper itself. So I think the simplest thing is for the
> remote-helper layer to do something like this:
I appreciate your root-causing this into the multi-process nature of
fetch. I will update the commit message to include your details,
especially about how it does not reproduce over file or ssh protocol.
> diff --git a/transport-helper.c b/transport-helper.c
> index 20a7185ec4..25957e9a05 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -14,6 +14,7 @@
> #include "refspec.h"
> #include "transport-internal.h"
> #include "protocol.h"
> +#include "packfile.h"
>
> static int debug;
>
> @@ -672,6 +673,7 @@ static int fetch(struct transport *transport,
> {
> struct helper_data *data = transport->data;
> int i, count;
> + int ret;
>
> get_helper(transport);
>
> @@ -710,13 +712,18 @@ static int fetch(struct transport *transport,
> if (data->transport_options.negotiation_tips)
> warning("Ignoring --negotiation-tip because the protocol does not support it.");
>
> - if (data->fetch)
> - return fetch_with_fetch(transport, nr_heads, to_fetch);
> + ret = data->fetch ? fetch_with_fetch(transport, nr_heads, to_fetch) :
> + data->import ? fetch_with_import(transport, nr_heads, to_fetch) :
> + -1;
>
> - if (data->import)
> - return fetch_with_import(transport, nr_heads, to_fetch);
> + /*
> + * We may have just received a pack through the helper sub-process;
> + * refresh the pack list.
> + */
> + if (!ret)
> + reprepare_packed_git(the_repository);
>
> - return -1;
> + return ret;
> }
This code looks correct, and should be the fix for the short-term.
I wonder if we could do something more complicated in the long-term,
which was recommended to me by Jeff Hostetler: add the pack to the
packed_git list once we've indexed it. That way, we don't reprepare
and scan the packs one-by-one, but instead we insert to the list
a single pack that we already know about.
Thanks,
-Stolee
next prev parent reply other threads:[~2020-03-13 0:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 15:36 [PATCH] connected.c: reprepare packs for corner cases Derrick Stolee via GitGitGadget
2020-03-12 16:39 ` Jonathan Tan
2020-03-12 17:34 ` Derrick Stolee
2020-03-12 20:42 ` Junio C Hamano
2020-03-12 21:16 ` Jeff King
2020-03-12 21:26 ` Jeff King
2020-03-13 0:54 ` Derrick Stolee [this message]
2020-03-13 1:14 ` Junio C Hamano
2020-03-13 2:30 ` Jeff King
2020-03-13 2:34 ` Jeff King
2020-03-13 12:43 ` Derrick Stolee
2020-03-13 21:11 ` [PATCH v2] " Derrick Stolee via GitGitGadget
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=7378a863-7e2a-455e-4635-e07938ef3381@gmail.com \
--to=stolee@gmail.com \
--cc=dstolee@microsoft.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
/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.