On 22/05/2024 21:55, Junio C Hamano wrote:
Tom Hughes <tom@xxxxxxxxxx> writes:
+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.
+ git clone --filter=blob:none "file://$(pwd)/server" client &&
+ test_commit -C client client1 &&
And make a clone out of it, without blobs.
+ 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.
+ 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.
+ 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".
+ 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@xxxxxxxxxx)
http://compton.nu/
