From: Tom Hughes Date: Wed, 22 May 2024 21:46:16 GMT Subject: Re: [PATCH v2] push: don't fetch commit object when checking existence Message-ID: <8f2ebf1b-050f-476a-92d4-dfb06ad04f8d@compton.nu> In-Reply-To: On 22/05/2024 21:55, Junio C Hamano wrote: > Tom Hughes 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@compton.nu) http://compton.nu/