On 22/05/2024 21:55, Junio C Hamano wrote:

Tom Hughes [off-list ref] writes:

quoted

+test_expect_success 'push should not fetch new commit objects' '
+	rm -rf server client &&
+	test_create_repo server &&
+	test_config -C server uploadpack.allowfilter 1 &&
+	test_config -C server uploadpack.allowanysha1inwant 1 &&
+	test_commit -C server server1 &&

OK, we create the source that allows a partial clone.

quoted

+	git clone --filter=blob:none "file://$(pwd)/server" client &&
+	test_commit -C client client1 &&

And make a clone out of it, without blobs.

quoted

+	test_commit -C server server2 &&
+	COMMIT=$(git -C server rev-parse server2) &&

Then we create a new commit that the client does not yet have.

quoted

+	test_must_fail git -C client push 2>err &&

We try to overwrite it.  We expect it to fail with "not a fast forward".

Well that is what it would fail with at the moment, but it's not
what would happen with a non-partial clone - a non-partial clone
would fail with "fetch first" instead.

This patch makes both cases consistent although that wasn't the
main driver - the main driver was to stop it fetching 100Mb or
more of history in the large repository I was working with when
the upstream has one new commit.

quoted

+	grep "fetch first" err &&

May want to use "test_grep" but this script does not use it, so
being consistent with the surrounding tests is good.

So here we are testing that it's a "fetch first" and rather
than "not a fast forward".

quoted

+	git -C client rev-list --objects --missing=print "$COMMIT" >objects &&
+	grep "^[?]$COMMIT" objects
+'

OK.

and also that it hasn't fetched the new commit.

Tom

-- 
Tom Hughes (tom@compton.nu)
http://compton.nu/