From: Junio C Hamano <gitster@pobox.com>
To: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, jonathantanmy@google.com, me@ttaylorr.com,
Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH] connected.c: reprepare packs for corner cases
Date: Thu, 12 Mar 2020 13:42:58 -0700 [thread overview]
Message-ID: <xmqqzhcle23x.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <pull.579.git.1584027403779.gitgitgadget@gmail.com> (Derrick Stolee via GitGitGadget's message of "Thu, 12 Mar 2020 15:36:43 +0000")
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Derrick Stolee <dstolee@microsoft.com>
>
> While updating the microsoft/git fork on top of v2.26.0-rc0 and
> consuming that build into Scalar, I noticed a corner case bug around
> partial clone.
>
> The "scalar clone" command can create a Git repository with the
> proper config for using partial clone with the "blob:none" filter.
> Instead of calling "git clone", it runs "git init" then sets a few
> more config values before running "git fetch".
>
> In our builds on v2.26.0-rc0, we noticed that our "git fetch"
> command was failing with
>
> error: https://github.com/microsoft/scalar did not send all necessary objects
>
> This does not happen if you copy the config file from a repository
> created by "git clone --filter=blob:none <url>", but it does happen
> when adding the config option "core.logAllRefUpdates = true".
>
> By debugging, I was able to see that the loop inside
> check_connnected() that checks if all refs are contained in
> promisor packs actually did not have any packfiles in the packed_git
> list.
> I'm not sure what corner-case issues caused this config option to
> prevent the reprepare_packed_git() from being called at the proper
> spot during the fetch operation. Even worse, I have failed to create
> a test case to prevent a regression.
>
> Placing a reprepare_packed_git() call inside chck_connected() before
> looping through the packed_git list seems like the safest way to
> avoid this issue in the future.
Hmmm. I am not sure if I am convinced that check_connected() is the
best place to do this. Do we know the place that adds a new pack to
the repository, yet forgets to add it to the packed-git list, that
caused the failure you were observing? Doing this change, without
describing the answer to the question in the log message, makes it
smell rather like a random hack than a designed solution to me.
If lazy fetching of objects happen in multiple fetches before a
single check_connected() sweeps them to check for connectivity, then
perhaps the lazy fetching codepath needs to remember the fact that
it added a new pack that is still not known to the packed-git list
(or just add it immediately, without having to scan at all), and
check_connected() would need to rescan only when there is at least
one such new pack? That way, you do not have to penalize normal
callers of check_connected() that do not use lazy fetches at all,
right?
Thanks.
next prev parent reply other threads:[~2020-03-12 20:43 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 [this message]
2020-03-12 21:16 ` Jeff King
2020-03-12 21:26 ` Jeff King
2020-03-13 0:54 ` Derrick Stolee
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzhcle23x.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=jonathantanmy@google.com \
--cc=me@ttaylorr.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).