From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: 程洋 <chengyang@xiaomi.com>,
"Derrick Stolee" <derrickstolee@github.com>,
"git@vger.kernel.org" <git@vger.kernel.org>,
何浩 <hehao@xiaomi.com>, "Xin7 Ma 马鑫" <maxin7@xiaomi.com>,
石奉兵 <shifengbing@xiaomi.com>, 凡军辉 <fanjunhui@xiaomi.com>,
王汉基 <wanghanji@xiaomi.com>
Subject: Re: [PATCH 2/3] upload-pack: skip parse-object re-hashing of "want" objects
Date: Wed, 07 Sep 2022 15:07:22 -0700 [thread overview]
Message-ID: <xmqq8rmususl.fsf@gitster.g> (raw)
In-Reply-To: <YxkG3A30vNfu55Sx@coredump.intra.peff.net> (Jeff King's message of "Wed, 7 Sep 2022 17:02:20 -0400")
Jeff King <peff@peff.net> writes:
> Subject: [PATCH] t1060: check partial clone of misnamed blob
>
> A recent commit (upload-pack: skip parse-object re-hashing of "want"
> objects, 2022-09-06) loosened the behavior of upload-pack so that it
> does not verify the sha1 of objects it receives directly via "want"
> requests. The existing corruption tests in t1060 aren't affected by
> this: the corruptions are blobs reachable from commits, and the client
> requests the commits.
>
> The more interesting case here is a partial clone, where the client will
> directly ask for the corrupted blob when it does an on-demand fetch of
> the filtered object. And that is not covered at all, so let's add a
> test.
>
> It's important here that we use the "misnamed" corruption and not
> "bit-error". The latter is sufficiently corrupted that upload-pack
> cannot even figure out the type of the object, so it bails identically
> both before and after the recent change. But with "misnamed", with the
> hash-checks enabled it sees the problem (though the error messages are a
> bit confusing because of the inability to create a "struct object" to
> store the flags):
Makes sense.
> error: hash mismatch d95f3ad14dee633a758d2e331151e950dd13e4ed
> fatal: git upload-pack: not our ref d95f3ad14dee633a758d2e331151e950dd13e4ed
> fatal: remote error: upload-pack: not our ref d95f3ad14dee633a758d2e331151e950dd13e4ed
>
> After the change to skip the hash check, the server side happily sends
> the bogus object, but the client correctly realizes that it did not get
> the necessary data:
>
> remote: Enumerating objects: 1, done.
> remote: Counting objects: 100% (1/1), done.
> remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
> Receiving objects: 100% (1/1), 49 bytes | 49.00 KiB/s, done.
> fatal: bad revision 'd95f3ad14dee633a758d2e331151e950dd13e4ed'
> error: [...]/misnamed did not send all necessary objects
>
> which is exactly what we expect to happen.
Thanks. Let's queue it on top.
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> t/t1060-object-corruption.sh | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/t/t1060-object-corruption.sh b/t/t1060-object-corruption.sh
> index 5b8e47e346..35261afc9d 100755
> --- a/t/t1060-object-corruption.sh
> +++ b/t/t1060-object-corruption.sh
> @@ -139,4 +139,11 @@ test_expect_success 'internal tree objects are not "missing"' '
> )
> '
>
> +test_expect_success 'partial clone of corrupted repository' '
> + test_config -C misnamed uploadpack.allowFilter true &&
> + git clone --no-local --no-checkout --filter=blob:none \
> + misnamed corrupt-partial && \
> + test_must_fail git -C corrupt-partial checkout --force
> +'
> +
> test_done
next prev parent reply other threads:[~2022-09-07 22:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 8:09 Partial-clone cause big performance impact on server 程洋
2022-08-11 17:22 ` Jonathan Tan
2022-08-13 7:55 ` 回复: [External Mail]Re: " 程洋
2022-08-13 11:41 ` 程洋
2022-08-15 5:16 ` ZheNing Hu
2022-08-15 13:15 ` 程洋
2022-08-12 12:21 ` Derrick Stolee
2022-08-14 6:48 ` Jeff King
2022-08-15 13:18 ` Derrick Stolee
2022-08-15 14:50 ` [External Mail]Re: " 程洋
2022-08-17 10:22 ` 程洋
2022-08-17 13:41 ` Derrick Stolee
2022-08-18 5:49 ` Jeff King
2022-09-01 6:53 ` 程洋
2022-09-01 16:19 ` Jeff King
2022-09-05 11:17 ` 程洋
2022-09-06 18:38 ` Jeff King
2022-09-06 22:58 ` [PATCH 0/3] speeding up on-demand fetch for blobs in partial clone Jeff King
2022-09-06 23:01 ` [PATCH 1/3] parse_object(): allow skipping hash check Jeff King
2022-09-07 14:15 ` Derrick Stolee
2022-09-07 20:44 ` Jeff King
2022-09-06 23:05 ` [PATCH 2/3] upload-pack: skip parse-object re-hashing of "want" objects Jeff King
2022-09-07 14:36 ` Derrick Stolee
2022-09-07 14:45 ` Derrick Stolee
2022-09-07 20:50 ` Jeff King
2022-09-07 19:26 ` Junio C Hamano
2022-09-07 20:36 ` Jeff King
2022-09-07 20:48 ` [BUG] t1800: Fails for error text comparison rsbecker
2022-09-07 21:55 ` Junio C Hamano
2022-09-07 22:23 ` rsbecker
2022-09-07 21:02 ` [PATCH 2/3] upload-pack: skip parse-object re-hashing of "want" objects Jeff King
2022-09-07 22:07 ` Junio C Hamano [this message]
2022-09-08 5:04 ` Jeff King
2022-09-08 16:41 ` Junio C Hamano
2022-09-06 23:06 ` [PATCH 3/3] parse_object(): check commit-graph when skip_hash set Jeff King
2022-09-07 14:46 ` Derrick Stolee
2022-09-07 19:31 ` Junio C Hamano
2022-09-08 10:39 ` [External Mail]Re: " 程洋
2022-09-08 18:42 ` Jeff King
2022-09-07 14:48 ` [PATCH 0/3] speeding up on-demand fetch for blobs in partial clone Derrick Stolee
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=xmqq8rmususl.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chengyang@xiaomi.com \
--cc=derrickstolee@github.com \
--cc=fanjunhui@xiaomi.com \
--cc=git@vger.kernel.org \
--cc=hehao@xiaomi.com \
--cc=maxin7@xiaomi.com \
--cc=peff@peff.net \
--cc=shifengbing@xiaomi.com \
--cc=wanghanji@xiaomi.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.
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.