From patchwork Sun Mar 9 03:01:23 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff King X-Patchwork-Id: 14008028 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE33E224CC for ; Sun, 9 Mar 2025 03:01:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.130.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489287; cv=none; b=lB5sjkIEbDd/yU47tK8/VoNYEkRzZ2ruA75vQdWHpwOSTP2Kj+TIJS7KdrQaTdsEcRbUEDl2vvuIwparxJuj7NbqQ8FJ8oRpQK8duNpw8uGjx0wdlK3qj0tuPe1r8qq96wAtpJGsmCBTjIYwtEPDKwDfDxvOxf6eLgnluyoYy1M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489287; c=relaxed/simple; bh=I5z1NNZCzzcfdzsTBIl8GcAKOysq3zllzOnQDwLOlxI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C/DUJ4GxlunFynksJySsr2wPtlKcOfvTOTnIzgr6tU4xjBERVrJz793wsm+NBDz4xZt12hJ2Fb1u5EZjkjN30Hp8kvM3y2C9yGECGc2JKTiUyF6MuOb4KwbxyHIGs1R6vLSF++fov91XPQ6TbZFDLEvAMAG8VtUMjrew/I3JXjc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net; spf=pass smtp.mailfrom=peff.net; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b=e7W+Ekau; arc=none smtp.client-ip=104.130.231.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peff.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b="e7W+Ekau" Received: (qmail 4625 invoked by uid 109); 9 Mar 2025 03:01:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=peff.net; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=20240930; bh=I5z1NNZCzzcfdzsTBIl8GcAKOysq3zllzOnQDwLOlxI=; b=e7W+EkaulDKJZPKkbPr4nNDeaX1kcgzSn/+z29WxsjdcZZF22o/xXu0I7YkeWNVvAql3pk69yWO9jYLTUJ3eSx6f3cbqeL6p4MCfR6mi/QAyV+ocA1IS/STv/DxM1tIWVFbUjDmd93W9/9OxN1lm4i8PNd+Tzc1v95yxknbuoZNbaAYdKwtTP0ZltbBgjF0Tu0yl/OIHlIJ5z+XA8gCCCGY/DoQCmxOnPdjXb0Es1c4Oyt6xyF+zFR/VuL98CoYHR5HbM1mA5V4VdTwCOYuYRyFEVw7oT7atMFKCI9gfHW5Y3HD2BOd9H4ATkCgQki2HFbYRJd81uucgD7UFdLIW6w== Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 09 Mar 2025 03:01:25 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 4807 invoked by uid 111); 9 Mar 2025 03:01:24 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 08 Mar 2025 22:01:24 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 8 Mar 2025 22:01:23 -0500 From: Jeff King To: Taylor Blau Cc: git@vger.kernel.org, Junio C Hamano , Igor Todorovski , Bence Ferdinandy Subject: [PATCH 1/9] t5702: fix typo in test name Message-ID: <20250309030123.GA2334191@coredump.intra.peff.net> References: <20250309030101.GA2334064@coredump.intra.peff.net> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250309030101.GA2334064@coredump.intra.peff.net> Signed-off-by: Jeff King --- t/t5702-protocol-v2.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh index d3df81e785..cea8f92a3d 100755 --- a/t/t5702-protocol-v2.sh +++ b/t/t5702-protocol-v2.sh @@ -665,7 +665,7 @@ test_expect_success 'even with handcrafted request, filter does not work if not test-tool -C server serve-v2 --stateless-rpc /dev/null ' -test_expect_success 'default refspec is used to filter ref when fetchcing' ' +test_expect_success 'default refspec is used to filter ref when fetching' ' test_when_finished "rm -f log" && GIT_TRACE_PACKET="$(pwd)/log" git -C file_child -c protocol.version=2 \ From patchwork Sun Mar 9 03:01:40 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff King X-Patchwork-Id: 14008029 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 906EB25761 for ; Sun, 9 Mar 2025 03:01:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.130.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489305; cv=none; b=QpqSVBYDqAyz2FC+MOxdbPjdaMUH0O+e8KMAXqzDAlxU/OCoCjsQSd3v/sJq+BjhTknBfH8Jx1dgGDICr+8vrnspcJPajwuvMEcbKV2kup6Pb1RfL72BE032vT2qPLQIk3xyeEk9IiSDoECzxOy1kG8sqghQDiBhQWVzfespRfY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489305; c=relaxed/simple; bh=LCafvU40/EOxmhMgkydloWMIwGDMYSR5fgmLmnMk6OI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=O4lx+x5nczbM23qt7wZH0cI9E+/cMQCtKNZWgjUFiBYTzJ43Flwgy3N522erutYsMH5JFDafRg3jdZHJCzSx5iV58VTTt4Hfqad5snuVu1Y+dYBnDrb5eTS2SEw/mVFNk9S7pFIaZU88MmGk/r4N0amej9yY5J7GFYA7SCFa4Bk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net; spf=pass smtp.mailfrom=peff.net; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b=b9pYPZR4; arc=none smtp.client-ip=104.130.231.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peff.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b="b9pYPZR4" Received: (qmail 4645 invoked by uid 109); 9 Mar 2025 03:01:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=peff.net; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=20240930; bh=LCafvU40/EOxmhMgkydloWMIwGDMYSR5fgmLmnMk6OI=; b=b9pYPZR4WDN33+Dfsfk2GzeGSraLzKVxdbArV5sXBCporCLCRRVHJPUSVMzJGoIinQ0GvtjJdUSL42/2nGB5N5ARjzs9VOF5nJgMokuoQZacB3pHlfCbEa/vupiIxtJfDjXVJkcUoSwwo5gRwXzWnYg4lo+srmpslFTmiY1eIhK6cP9bT49qX0ZyYLsvHHGeiJQkERkpR8NW85tqVMEakfWtQ3NXkse0QKQzrwjLsSRa8jPqItDw5eYezzI/Pl3YUKwb/9VmSSO90jaEYeS8XTl6GpErYMwSYe6P6oRePgDfqMEedIgagLXw9dV6QyJHWL7fmD9nURasOcMLX8XPWg== Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 09 Mar 2025 03:01:41 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 4817 invoked by uid 111); 9 Mar 2025 03:01:41 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 08 Mar 2025 22:01:41 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 8 Mar 2025 22:01:40 -0500 From: Jeff King To: Taylor Blau Cc: git@vger.kernel.org, Junio C Hamano , Igor Todorovski , Bence Ferdinandy Subject: [PATCH 2/9] t5516: prefer "oid" to "sha1" in some test titles Message-ID: <20250309030140.GB2334191@coredump.intra.peff.net> References: <20250309030101.GA2334064@coredump.intra.peff.net> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250309030101.GA2334064@coredump.intra.peff.net> These old tests refer to object ids as "sha1". These days we prefer the more algorithm-agnostic "oid". There are a few more tests that mention sha1 in the title and also use it in variables throughout the test. I've left them for now, as changing them is more involved (and they're linked to the allowTipSHA1InWant config, which as a v0-only thing actually is always sha1). Signed-off-by: Jeff King --- t/t5516-fetch-push.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 85ed049627..e7629fc536 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -495,7 +495,7 @@ test_expect_success 'push tag with non-existent, incomplete dest' ' ' -test_expect_success 'push sha1 with non-existent, incomplete dest' ' +test_expect_success 'push oid with non-existent, incomplete dest' ' mk_test testrepo && test_must_fail git push testrepo $(git rev-parse main):foo @@ -1251,7 +1251,7 @@ do ' done -test_expect_success 'fetch exact SHA1' ' +test_expect_success 'fetch exact oid' ' mk_test testrepo heads/main hidden/one && git push testrepo main:refs/hidden/one && ( @@ -1297,7 +1297,7 @@ test_expect_success 'fetch exact SHA1' ' ) ' -test_expect_success 'fetch exact SHA1 in protocol v2' ' +test_expect_success 'fetch exact oid in protocol v2' ' mk_test testrepo heads/main hidden/one && git push testrepo main:refs/hidden/one && git -C testrepo config transfer.hiderefs refs/hidden && From patchwork Sun Mar 9 03:02:03 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff King X-Patchwork-Id: 14008030 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8748C25761 for ; Sun, 9 Mar 2025 03:02:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.130.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489327; cv=none; b=Sq7Z05KDygEItwLZTE98ap0RUjaPJBUbiHzcKvDDCBYKy0cCHRMS/5IRpkyctGsYBnJdS++T7w7S35OzsnUoo52ur3YpVIYnqt0eg8Ry159jTpkInsgVWKxXqGEtrHVujynF5YPiW8HLbQopqr9yhlkT8zbbiut8tZuyp3+ps8I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489327; c=relaxed/simple; bh=GYFVyiABaso/kWaT3cqmRkAlB2x73+9taSCNUwXIXEo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IGa8Rh5zsuyQud6MJZQ0Y3o7zmmUPTNYozf1+j9ZmlDOlyVPm0vsX+Eizt91h5vRZEfbAnRkYcSMwPt5mPtvRfrTeGuJq+LuQeLHqYy2RH+OTsjiX37IPcUhMz2qaH2gKv2n41aTrCF1GuIpPiiIpVjZ+8xZG+hJzxSTpx+SXBY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net; spf=pass smtp.mailfrom=peff.net; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b=BVhmjI8G; arc=none smtp.client-ip=104.130.231.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peff.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b="BVhmjI8G" Received: (qmail 4658 invoked by uid 109); 9 Mar 2025 03:02:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=peff.net; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=20240930; bh=GYFVyiABaso/kWaT3cqmRkAlB2x73+9taSCNUwXIXEo=; b=BVhmjI8GBImWC0nY+i4Fs6VU0qPn708M2BUNde46Q6svJrtzje/IapUiXBRaHf6K2xHjdJLosZpu0/40lGFC7zOUh/XKl35qmiGAK/V6nXA+bPV8kredJrdgxqWGfV6EclU6/iYrZvOML9vTunpNEQKwESZse0RboMwcsF6fcoSUU/rqI51sweVrqEgH62mtQcQZy24dFaTpfot6CvtU3EbANm5qLFLcEy6McNccHx+SMcM3OwHBEFNr1s8BUEQWhaidEtRApzzkhLH2CVCBxHmtLpYG3/OmyZrpTSvw876LRPm8MEQztYgqn5eVwZZy7xiKA/vAYMGvs0qy/MleXA== Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 09 Mar 2025 03:02:04 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 4824 invoked by uid 111); 9 Mar 2025 03:02:04 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 08 Mar 2025 22:02:04 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 8 Mar 2025 22:02:03 -0500 From: Jeff King To: Taylor Blau Cc: git@vger.kernel.org, Junio C Hamano , Igor Todorovski , Bence Ferdinandy Subject: [PATCH 3/9] t5516: drop NEEDSWORK about v2 reachability behavior Message-ID: <20250309030203.GC2334191@coredump.intra.peff.net> References: <20250309030101.GA2334064@coredump.intra.peff.net> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250309030101.GA2334064@coredump.intra.peff.net> When this test was added in 6c301adb0a (fetch: do not pass ref-prefixes for fetch by exact SHA1, 2018-05-31), there was still some uncertainty about the v2 protocol's looser behavior with serving objects that are not directly pointed at by a ref. At this point that behavior is well established, and I do not think we would ever change v2 to match the v0 behavior (and if we did, remembering to update this test is the least of our concerns). Signed-off-by: Jeff King --- t/t5516-fetch-push.sh | 1 - 1 file changed, 1 deletion(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index e7629fc536..e4008f3ca6 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -1312,7 +1312,6 @@ test_expect_success 'fetch exact oid in protocol v2' ' test_must_fail git -C child cat-file -t $the_commit && # fetching the hidden object succeeds by default - # NEEDSWORK: should this match the v0 behavior instead? git -C child fetch -v ../testrepo $the_commit:refs/heads/copy ' From patchwork Sun Mar 9 03:02:47 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff King X-Patchwork-Id: 14008031 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 32DBD17BD6 for ; Sun, 9 Mar 2025 03:02:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.130.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489370; cv=none; b=El0JUPF8zYB82aJ4gJMx7hGxroFp60nJ/widtOH38uoZOVy7cyIbYRq7HvPIu4asFyVJD5h4U06mEBJoxoE4PxRj2Q5xJBHXbWlJGlZclchIXFSRs+SSHdXXrCMe50r+74c63NlVTu6TsXsJzEG1Aj2m4oFavg3dza4mNtMAYFU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489370; c=relaxed/simple; bh=xx374hruO2O3mr/5Ik5tTQn8FmcDHOIaGbe2/aRI4GA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KyMsyvJLaIVDw/d0LW2QfQaPtCMkZ7rUJjjJNr1ZG6vXsygBCO+gLLGXqUOJQITywpygTziaYGvss7i2uxcl6RbeVUZ+6zFOV6MSlEF/QLSYUOMy6s6eHud859jEMe+icMcdUkJl/zxcOd0lw0xc1iv214kzpg3E0HO8LQVI/CQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net; spf=pass smtp.mailfrom=peff.net; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b=OtLskgt3; arc=none smtp.client-ip=104.130.231.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peff.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b="OtLskgt3" Received: (qmail 4678 invoked by uid 109); 9 Mar 2025 03:02:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=peff.net; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=20240930; bh=xx374hruO2O3mr/5Ik5tTQn8FmcDHOIaGbe2/aRI4GA=; b=OtLskgt3TIB6ul+aSIK09s/2cu80luSHfWuueP+PWhTaurLlDsHBXbWIOqwhwAq6I2HnMwEwvz8MvkptJprIFM7lD2oq49QbUTCpB1ImNCeLAy9hHyUqwlxCzSCeiNQra/CEso9EE03l9jFyfPFHpiWIMr//lj/iCKpFNGPqqIBAz8YTaet/5I10DV2oLzTTdnC7Z2PjAdVhs6RIN4AJcGrWmhWDAkC3kQHDPCQxXGPLgjJCgaMb54FXOQO5PTjMUs7Kd+99w0RzYw4E0MlrGA8acrYe9YqAjqM/0fbwtvCWxieAKgxuudy2vAEPVcv3qA8mqEjlHILMUk15IX+VfQ== Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 09 Mar 2025 03:02:48 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 4831 invoked by uid 111); 9 Mar 2025 03:02:47 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 08 Mar 2025 22:02:47 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 8 Mar 2025 22:02:47 -0500 From: Jeff King To: Taylor Blau Cc: git@vger.kernel.org, Junio C Hamano , Igor Todorovski , Bence Ferdinandy Subject: [PATCH 4/9] t5516: beef up exact-oid ref prefixes test Message-ID: <20250309030247.GD2334191@coredump.intra.peff.net> References: <20250309030101.GA2334064@coredump.intra.peff.net> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250309030101.GA2334064@coredump.intra.peff.net> Commit 6c301adb0a (fetch: do not pass ref-prefixes for fetch by exact SHA1, 2018-05-31) added a test that fetching an exact oid with the v2 protocol works. Originally it failed without the code change from that commit, because fetch failed with "no matching remote head". That changed in 0177565148 (transport: do not list refs if possible, 2018-09-27), which made fetch more forgiving of this case. But that now meant the test passes even without its fix! So let's also have it check the packet listing to make sure we did not ask for the bogus prefix (ultimately this is less important than whether the command fails, since it's just an optimization, but we should make sure not to regress it). Signed-off-by: Jeff King --- t/t5516-fetch-push.sh | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index e4008f3ca6..2904399e97 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -1312,7 +1312,10 @@ test_expect_success 'fetch exact oid in protocol v2' ' test_must_fail git -C child cat-file -t $the_commit && # fetching the hidden object succeeds by default - git -C child fetch -v ../testrepo $the_commit:refs/heads/copy + GIT_TRACE_PACKET=$PWD/trace.out \ + git -C child fetch -v ../testrepo $the_commit:refs/heads/copy && + + test_grep ! "ref-prefix.*$the_commit" trace.out ' for configallowtipsha1inwant in true false From patchwork Sun Mar 9 03:07:06 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff King X-Patchwork-Id: 14008032 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 292833209 for ; Sun, 9 Mar 2025 03:07:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.130.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489629; cv=none; b=Gk4MuDc4g6B+rwbKQrkSv8RURJS1hMj3p6B3nbLL3MR2eJWlmg8INNpE9/E8v4I9TkCm52Y2KfXjvn6cGobYCBMYES6lD0RdyneV9MlmCEesY6uY6Aw+S0JXRKWOsk9O8LZbYTLtUIKHgibKYbmSbQSqbcAtXEPiOXUkFURa3c0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489629; c=relaxed/simple; bh=gT7/ZFv6rC20DRIwYynuIOgVtIBbc1eOqQP/18eQYcQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UcbtaYevETGrEHhoBeysYHLAugy2T2XqyQHUb6YNLLS5bY0uMoy8dZ7jfIBUNSmJgJJQeDITtHe+JhQd210M4qHXLPQ5Gbhq2BHXHhY2uQncNIxk2uXS8tbz3baC9OqYcMjxTsCYJCrMcDhECWaWAvWD5/tFawIhz2qSXL8Bf94= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net; spf=pass smtp.mailfrom=peff.net; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b=QcqabLRr; arc=none smtp.client-ip=104.130.231.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peff.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b="QcqabLRr" Received: (qmail 4737 invoked by uid 109); 9 Mar 2025 03:07:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=peff.net; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=20240930; bh=gT7/ZFv6rC20DRIwYynuIOgVtIBbc1eOqQP/18eQYcQ=; b=QcqabLRrHNoezmKGOP6UrG6cV5kvlFrwL1+d19K+MjASWeiqAgtTVHjp7Qgzf6p6VCvzsgNBZ3UBmksKfpbQdnySKBxLRjDw+z34SJxKy402G6MUCdd3yk6GHAuOAoFHu2KQy6Q5agAmJOstFV5APV1ljJGFOOViBAhbZ1RbMuaXno8lTn6E8+Z7gCoaJUtRV0va7ptmVgyAJ8dNXQ2srUu13BzWMABCRXrOWz/bD2n3opAiSxwuuqQOgzX7isEumv/rWoR9zSKDG6E0YbliUrauaEi3HP9xtFfBNJNWArF9lBHUB/SR5weFLO5Y9M+9uYGpR/mrwAFnmrx/w56Jrg== Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 09 Mar 2025 03:07:07 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 4912 invoked by uid 111); 9 Mar 2025 03:07:06 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 08 Mar 2025 22:07:06 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 8 Mar 2025 22:07:06 -0500 From: Jeff King To: Taylor Blau Cc: git@vger.kernel.org, Junio C Hamano , Igor Todorovski , Bence Ferdinandy Subject: [PATCH 5/9] refspec_ref_prefixes(): clean up refspec_item logic Message-ID: <20250309030706.GE2334191@coredump.intra.peff.net> References: <20250309030101.GA2334064@coredump.intra.peff.net> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250309030101.GA2334064@coredump.intra.peff.net> The point of refspec_ref_prefixes() is to look over the set of refspecs and set up an appropriate list of "ref-prefix" strings to send to the server. The logic for handling individual refspec_items has some confusing bits. The final part of our if/else cascade checks this: else if (item->src && !item->exact_sha1) prefix = item->src; But we know that "item->exact_sha1" can never be true, because earlier we did: if (item->exact_sha1 || item->negative) continue; This is due to 6c301adb0a (fetch: do not pass ref-prefixes for fetch by exact SHA1, 2018-05-31), which added the continue. So it is tempting to remove the extra exact_sha1 at the end of the cascade, leaving the one at the top of the loop. But I don't think that's quite right. The full cascade is: if (rs->fetch == REFSPEC_FETCH) prefix = item->src; else if (item->dst) prefix = item->dst; else if (item->src && !item->exact_sha1) prefix = item->src; which all comes from 6373cb598e (refspec: consolidate ref-prefix generation logic, 2018-05-16). That first "if" is supposed to handle fetches, where we care about the source name, since that is coming from the server. And the rest should be for pushes, where we care about the destination, since that's the name the server will use. And we get that either explicitly from "dst" (for something like "foo:bar") or implicitly from the source (a refspec like "foo" is treated as "foo:foo"). But how should exact_sha1 interact with those? For a fetch, exact_sha1 always means we do not care about sending a name to the server (there is no server refname at all). But pushing an exact sha1 should still care about the destination on the server! It is only if we have to fall back to the implicit source that we need to care if it is a real ref (though arguably such a push does not even make sense; where would the server store it?). So I think that 6c301adb0a "broke" the push case by always skipping exact_sha1 items, even though a push should only care about the destination. Of course this is all completely academic. We have still not implemented a v2 push protocol, so even though we do call this function for pushes, we'd never actually send these ref-prefix lines. However, given the effort I spent to figure out what was going on here, and the overlapping exact_sha1 checks, I'd like to rewrite this to preemptively fix the bug, and hopefully make it less confusing. This splits the "if" at the top-level into fetch vs push, and then each handles exact_sha1 appropriately itself. The check for negative refspecs remains outside of either (there is no protocol support for them, so we never send them to the server, but rather use them only to reduce the advertisement we receive). The resulting behavior should be identical for fetches, but hopefully sets us up better for a potential future v2 push. Signed-off-by: Jeff King --- This could be dropped without affecting the rest of the series if it's too churn-y. refspec.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/refspec.c b/refspec.c index 4cb80b5208..c6ad515f04 100644 --- a/refspec.c +++ b/refspec.c @@ -246,14 +246,24 @@ void refspec_ref_prefixes(const struct refspec *rs, const struct refspec_item *item = &rs->items[i]; const char *prefix = NULL; - if (item->exact_sha1 || item->negative) + if (item->negative) continue; - if (rs->fetch == REFSPEC_FETCH) - prefix = item->src; - else if (item->dst) - prefix = item->dst; - else if (item->src && !item->exact_sha1) + + if (rs->fetch == REFSPEC_FETCH) { + if (item->exact_sha1) + continue; prefix = item->src; + } else { + /* + * Pushes can have an explicit destination like + * "foo:bar", or can implicitly use the src for both + * ("foo" is the same as "foo:foo"). + */ + if (item->dst) + prefix = item->dst; + else if (item->src && !item->exact_sha1) + prefix = item->src; + } if (!prefix) continue; From patchwork Sun Mar 9 03:08:47 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff King X-Patchwork-Id: 14008033 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1F3B3209 for ; Sun, 9 Mar 2025 03:08:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.130.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489730; cv=none; b=Xd3WmOMJnp90CRYIAGuXupIl7gbsyY8t8VB0k/bnH7HyDKXD57tawqJdpz5+A45c/WQTvZZQ7dnLBmtL7++rZzOY9YnMV+/iMPLGbdF2kr06yDRd6/oLQwWsswKyhb4AD52jL8erraapYwzBN8ZlUtQ0LNVW9wJUNngSN5hnXS4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489730; c=relaxed/simple; bh=hK9QnUOQ4a9I862iyrZNezxh/8O/gzZwhJkqiOdAz7o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RXerhbVNkO5ycfwGrBLE47h+AEgzdgW2gpoW8/XzC6ZGWPtHjDhmYTjvbyYGQm1X1VVoZ0uKCtCeXbfa2qLMblLraQwumr03jXydYb9lxf0Ndnno66MisXEdYNsO3u1ThxkQy1iwfKszCLPz/MFp45snzJo6QanqOMgcz+l4vLA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net; spf=pass smtp.mailfrom=peff.net; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b=Lxdw0yFU; arc=none smtp.client-ip=104.130.231.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peff.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b="Lxdw0yFU" Received: (qmail 4778 invoked by uid 109); 9 Mar 2025 03:08:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=peff.net; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=20240930; bh=hK9QnUOQ4a9I862iyrZNezxh/8O/gzZwhJkqiOdAz7o=; b=Lxdw0yFU5NjOCWJp8KqDrUJY85pyoDmnkeSLAQafUGnV0x6d7iQLpn7ed4DVMitRrYFciJPBl4oZ1IpSWzfs3ynjTwvtT3zzY7H7gaBTWr4vjM+blL1EUnT2tmiVAcQnL7Rsa+8VggjORUP0NnoBR2+6qeab1grXeGfasWpgZdzviBC4G98CxOnDvgbIRyKKTWhXkkAHyrnRv2h9EKcNYBX7SwvWfZD4/oe/a0C6MApdDMKWCo1qqswHpBdpcv9ZUxZNaEy58c47qVfom0R0KZZZLg0uHmlFtf9YF4OIG7cbLnl4yVS++3GireuwxbAQFF2R2xXjE5Q1FryAExWEhw== Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 09 Mar 2025 03:08:48 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 4939 invoked by uid 111); 9 Mar 2025 03:08:47 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 08 Mar 2025 22:08:47 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 8 Mar 2025 22:08:47 -0500 From: Jeff King To: Taylor Blau Cc: git@vger.kernel.org, Junio C Hamano , Igor Todorovski , Bence Ferdinandy Subject: [PATCH 6/9] fetch: ask server to advertise HEAD for config-less fetch Message-ID: <20250309030847.GF2334191@coredump.intra.peff.net> References: <20250309030101.GA2334064@coredump.intra.peff.net> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250309030101.GA2334064@coredump.intra.peff.net> If we're not given any refspecs (either on the command line or via config) and we have no branch merge config, then we fetch the remote HEAD into our local FETCH_HEAD. In that case we do not send any ref-prefix option to the server at all, and we see the full advertisement. But this is sub-optimal. We only care about HEAD, so we can just ask for that, and ignore all of the other refs. The new test demonstrates a case where we see fewer refs (in this case only one less, but in theory we could be ignoring millions of them). This also removes the only case where we care about seeing some refs from the other side, but don't add anything to the ref_prefixes list. Cleaning this up means one less maintenance burden. Before this patch, any code which wanted to add to the list had to make sure the list was not empty, since an empty list meant "ask for everything". Now it really means "we are not interested in any refs". This should let us optimize a few more cases in subsequent patches. Note that we'll add "HEAD" to the list of prefixes, and later code for updating "refs/remotes//HEAD" may likewise do so. In theory this could cause duplicates in the list, but in practice these can't both trigger. We hit our new case only if there are no refspecs, and the "/HEAD" feature is enabled only when we are fetching from a remote with configured refspecs. We could be defensive with a flag, but it didn't seem worth it to me (the absolute worse case is a useless redundant ref-prefix line sent to the server). Signed-off-by: Jeff King --- builtin/fetch.c | 8 ++++++++ t/t5702-protocol-v2.sh | 15 +++++++++++++++ 2 files changed, 23 insertions(+) diff --git a/builtin/fetch.c b/builtin/fetch.c index 95fd0018b9..f142756441 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -1766,6 +1766,14 @@ static int do_fetch(struct transport *transport, branch->merge[i]->src); } } + + /* + * If there are no refs specified to fetch, then we just + * fetch HEAD; mention that to narrow the advertisement. + */ + if (!transport_ls_refs_options.ref_prefixes.nr) + strvec_push(&transport_ls_refs_options.ref_prefixes, + "HEAD"); } if (tags == TAGS_SET || tags == TAGS_DEFAULT) { diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh index cea8f92a3d..2f0a52a72d 100755 --- a/t/t5702-protocol-v2.sh +++ b/t/t5702-protocol-v2.sh @@ -679,6 +679,21 @@ test_expect_success 'default refspec is used to filter ref when fetching' ' grep "ref-prefix refs/tags/" log ' +test_expect_success 'set up parent for prefix tests' ' + git init prefix-parent && + git -C prefix-parent commit --allow-empty -m foo && + git -C prefix-parent branch unrelated-branch +' + +test_expect_success 'empty refspec filters refs when fetching' ' + git init configless-child && + + test_when_finished "rm -f log" && + GIT_TRACE_PACKET="$(pwd)/log" \ + git -C configless-child fetch ../prefix-parent && + test_grep ! unrelated-branch log +' + test_expect_success 'fetch supports various ways of have lines' ' rm -rf server client trace && git init server && From patchwork Sun Mar 9 03:10:39 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff King X-Patchwork-Id: 14008034 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 818EC3209 for ; Sun, 9 Mar 2025 03:10:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.130.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489845; cv=none; b=LwTyoJIWXTtn7p93b3fauwPmY901Z0twHmftBoT0ITmGCPIUJibQHGzZoAkcifJwws1xboUazTywHCy1VOmXYPsk595Fc6dJkRoiPVxdYf+tvIiITAkOvMhJybR6/h2Mcve5ZXqCGqEShXwWABO2uWbC+WVWPrjFSeR7YZD93/U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741489845; c=relaxed/simple; bh=1Z3foLPQzWARbRt/Mlws5YuN9WcvabLcv6fDkW4RVEc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ikee0/XjPygkEy35QKQWE47DLO7krx2hrRffAXxUJ6YrQD2mRbUaEGvunSzPchSqwXSbXueUYWMqcUkXsqMhk202J7aBMQx+UFoRsc0thB0E98qOuZobGQQjONHO0sRDuurckQ7Y2f9Q3PeuNX7jv2WlHghr/N2o7t2f02tcHhs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net; spf=pass smtp.mailfrom=peff.net; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b=Sz5SWTNK; arc=none smtp.client-ip=104.130.231.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peff.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b="Sz5SWTNK" Received: (qmail 4804 invoked by uid 109); 9 Mar 2025 03:10:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=peff.net; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=20240930; bh=1Z3foLPQzWARbRt/Mlws5YuN9WcvabLcv6fDkW4RVEc=; b=Sz5SWTNKQo+vflLnm2gM34UH8/Pjd50tTc0jS7r1LkXZ3XhyD1vM1lI3Fr2jdMP9ubuIC1iS8a+Qfn27aO5bfyP3heu8FpxxNBOt7U/wYjSfh0DQsrt27w5KL7vAApgqdmB+pxejaab7up+wcwAgRcUn7etmS1Tt9NAfoA190/BpzIYiaTyy53znfltXg6IfFkKKOZLCdxiFSCtOBT7QsjX0GlqF7Z1RhBlLUbHEFnAEjsY8VqMCG2DK8uUxITfVebN5t6I5ZbAChtbM6/y9UqWQoOxNaoS03sXVdwDXsYkEsuvyJheBcpKJEGZSIbIhVYSyWl/w1WObgIygM7Abmw== Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 09 Mar 2025 03:10:40 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 4974 invoked by uid 111); 9 Mar 2025 03:10:40 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 08 Mar 2025 22:10:40 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 8 Mar 2025 22:10:39 -0500 From: Jeff King To: Taylor Blau Cc: git@vger.kernel.org, Junio C Hamano , Igor Todorovski , Bence Ferdinandy Subject: [PATCH 7/9] fetch: stop protecting additions to ref-prefix list Message-ID: <20250309031039.GG2334191@coredump.intra.peff.net> References: <20250309030101.GA2334064@coredump.intra.peff.net> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250309030101.GA2334064@coredump.intra.peff.net> When using the ref-prefix feature of protocol v2, a client which sends no prefixes at all will get the full advertisement. And so the code in git-fetch was historically loose about setting up that list based on our refspecs. There were cases where we needed to know about some refs, so we just didn't add anything to the ref-prefix list. And hence further code, like that for tag-following and updating origin/HEAD, had to be careful about adding to an empty list. E.g., see the bug fixed by bd52d9a058 (fetch: fix following tags when fetching specific OID, 2025-03-07). But the previous commit removed the last such case, and now we know an empty ref-prefix list (at least inside git-fetch's do_fetch() function) means that we really don't need to see any refs. So we can drop those extra conditionals. This simplifies the code a little. But it also means that some cases can now use ref prefixes when they would not otherwise. As the test shows, fetching an exact oid into a local ref can now avoid enumerating all of the refs. The refspec itself doesn't need to know about any remote refs, and the tag auto-following can just ask about refs/tags/. The same is true for asking about HEAD to update the local origin/HEAD. I didn't add a test for that yet, though, as we can optimize it even further. Signed-off-by: Jeff King --- builtin/fetch.c | 10 ++++------ t/t5702-protocol-v2.sh | 14 ++++++++++++++ 2 files changed, 18 insertions(+), 6 deletions(-) diff --git a/builtin/fetch.c b/builtin/fetch.c index f142756441..6ab101fa6d 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -1778,16 +1778,14 @@ static int do_fetch(struct transport *transport, if (tags == TAGS_SET || tags == TAGS_DEFAULT) { must_list_refs = 1; - if (transport_ls_refs_options.ref_prefixes.nr) - strvec_push(&transport_ls_refs_options.ref_prefixes, - "refs/tags/"); + strvec_push(&transport_ls_refs_options.ref_prefixes, + "refs/tags/"); } if (uses_remote_tracking(transport, rs)) { must_list_refs = 1; - if (transport_ls_refs_options.ref_prefixes.nr) - strvec_push(&transport_ls_refs_options.ref_prefixes, - "HEAD"); + strvec_push(&transport_ls_refs_options.ref_prefixes, + "HEAD"); } if (must_list_refs) { diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh index 2f0a52a72d..626deb05f0 100755 --- a/t/t5702-protocol-v2.sh +++ b/t/t5702-protocol-v2.sh @@ -682,6 +682,7 @@ test_expect_success 'default refspec is used to filter ref when fetching' ' test_expect_success 'set up parent for prefix tests' ' git init prefix-parent && git -C prefix-parent commit --allow-empty -m foo && + git -C prefix-parent tag my-tag && git -C prefix-parent branch unrelated-branch ' @@ -694,6 +695,19 @@ test_expect_success 'empty refspec filters refs when fetching' ' test_grep ! unrelated-branch log ' +test_expect_success 'exact oid fetch with tag following' ' + git init exact-oid-tags && + + commit=$(git -C prefix-parent rev-parse --verify HEAD) && + + test_when_finished "rm -f log" && + GIT_TRACE_PACKET="$(pwd)/log" \ + git -C exact-oid-tags fetch ../prefix-parent \ + $commit:refs/heads/exact && + test_grep ! unrelated-branch log && + git -C exact-oid-tags rev-parse --verify my-tag +' + test_expect_success 'fetch supports various ways of have lines' ' rm -rf server client trace && git init server && From patchwork Sun Mar 9 03:20:16 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff King X-Patchwork-Id: 14008035 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0A61A1FC8 for ; Sun, 9 Mar 2025 03:20:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.130.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741490419; cv=none; b=k2zSsD9iFKqeO/4xcWRLc7qHga9SUc82K9/LCxmr8sKIWMksp+ZOeTsercmcsuBimqQeg3bQF6nps8FkFslt1UABJzUxwBGPUsyjfmdTcoR0UPa4l58rmDxIrQ2P7gJP2NeozA6N9jeZPqFMVYmPm5dV76QSqfpKk3ZuR/slAaY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741490419; c=relaxed/simple; bh=/xPY1z5CS8RmFHYt7ph+GU1wU4AM0HWpNteoNyhnnng=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r9OTstS3ax2eknvTMEWcGwrGgPyvxDcOdNOR9uLhySeZZ56tsV6yC9v7O/Dv2bCX3KHFBUvt4AovQRo9DzLOoU67CMWca0iIuMwzyJH6IO0olMINAxbGE8GPnJ4uu/7dRYvoAX7CANRPqNwk1L83v81UyN0uPRp1bGSblaWSsrM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net; spf=pass smtp.mailfrom=peff.net; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b=F6zg5+K+; arc=none smtp.client-ip=104.130.231.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peff.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b="F6zg5+K+" Received: (qmail 4969 invoked by uid 109); 9 Mar 2025 03:20:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=peff.net; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=20240930; bh=/xPY1z5CS8RmFHYt7ph+GU1wU4AM0HWpNteoNyhnnng=; b=F6zg5+K+SlY5GV981yiwmP6ZpGBTNrPEoEJvD2FsMXLcAHftw+6NV0nzBfo0wEBtgK7JUUGP1z07CXGn8QxgAJa+8vtTxsSxJ2qdRSWaXH96XAII6Ob8V7Ve/jt732dS0+DVZoSJDLvfx8wUraeoW2DVD56ac0BVKw5VSuN32Pd459yaqlQlQxwYWBaIHNEASSHZBdDsIIpTeP2s0ZgGzpaS9xJSf6cvuhkap3iBovieHQeG+IILAgGvBJdwRhayaewYLOhgdNOGniFO39rYuZfawxfn4j1d76NXV176CSWuQGoUapZu8E6ERFRDDP6NGYQTS0WC4g+cXBieX0kUEQ== Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 09 Mar 2025 03:20:17 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 5084 invoked by uid 111); 9 Mar 2025 03:20:16 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 08 Mar 2025 22:20:16 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 8 Mar 2025 22:20:16 -0500 From: Jeff King To: Taylor Blau Cc: git@vger.kernel.org, Junio C Hamano , Igor Todorovski , Bence Ferdinandy Subject: [PATCH 8/9] fetch: avoid ls-refs only to ask for HEAD symref update Message-ID: <20250309032016.GH2334191@coredump.intra.peff.net> References: <20250309030101.GA2334064@coredump.intra.peff.net> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250309030101.GA2334064@coredump.intra.peff.net> When we fetch from a configured remote, we may try to update the local refs/remotes//HEAD, and so we ask the server to advertise its HEAD to us. But if we aren't otherwise asking about any refs at all, then we know this HEAD update can never happen! To consider a new value for HEAD, the set_head() function uses guess_remote_head(). And even if it sees an explicit symref value for HEAD, it will only report that as a match if we also saw that remote ref advertised, and it mapped to a local tracking ref via get_fetch_map(). In other words, a fetch like this: git fetch origin $exact_oid:refs/heads/foo can never update HEAD, because we will never have fetched (nor even see the advertisement for) the ref that HEAD points to. Currently the command above will still call ls-refs to ask about the HEAD, even though it is pointless. This patch teaches it to skip the ls-refs call entirely in this case, which avoids a round-trip to the server. Signed-off-by: Jeff King --- This describes the current behavior of set_head(). But I do wonder if it should be more aggressive. If we found out that the other side is pointing to refs/heads/foo, should we map that ourselves to find that it would be stored as refs/remotes/origin/foo, and update HEAD anyway? That would let us actually update HEAD in this case (and also in many other cases where we fetch a specific ref that is not pointed to by the remote HEAD). OTOH, it would mean we basically always do an ls-refs just to find out about HEAD. Which is working against the optimization from e70a3030e7 (fetch: do not list refs if fetching only hashes, 2018-09-27), and the code before this patch might even be considered a regression. I also wonder if the uses_remote_tracking() check added by 6c915c3f85 (fetch: do not ask for HEAD unnecessarily, 2024-12-06) is not quite right. It is looking for a configured remote along with at least one refspec with a destination. But wouldn't it need to have both a source ref (not an exact oid) and a destination to work? I suspect we could do the fix there and end up with the same optimized behavior as I have here. builtin/fetch.c | 5 ++--- t/t5702-protocol-v2.sh | 13 +++++++++++++ 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/builtin/fetch.c b/builtin/fetch.c index 6ab101fa6d..c26866e674 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -1782,11 +1782,10 @@ static int do_fetch(struct transport *transport, "refs/tags/"); } - if (uses_remote_tracking(transport, rs)) { - must_list_refs = 1; + if (must_list_refs && + uses_remote_tracking(transport, rs)) strvec_push(&transport_ls_refs_options.ref_prefixes, "HEAD"); - } if (must_list_refs) { trace2_region_enter("fetch", "remote_refs", the_repository); diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh index 626deb05f0..4d0cbe9872 100755 --- a/t/t5702-protocol-v2.sh +++ b/t/t5702-protocol-v2.sh @@ -708,6 +708,19 @@ test_expect_success 'exact oid fetch with tag following' ' git -C exact-oid-tags rev-parse --verify my-tag ' +test_expect_success 'exact oid fetch avoids pointless HEAD request' ' + git init exact-oid-head && + git -C exact-oid-head remote add origin ../prefix-parent && + + commit=$(git -C prefix-parent rev-parse --verify HEAD) && + + test_when_finished "rm -f log" && + GIT_TRACE_PACKET="$(pwd)/log" \ + git -C exact-oid-head fetch --no-tags origin \ + $commit:refs/heads/exact && + test_grep ! command=ls-refs log +' + test_expect_success 'fetch supports various ways of have lines' ' rm -rf server client trace && git init server && From patchwork Sun Mar 9 03:21:59 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff King X-Patchwork-Id: 14008036 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D4F414A85 for ; Sun, 9 Mar 2025 03:22:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.130.231.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741490523; cv=none; b=LZtT5u2YGPMYTZ7prT1jvPJVoahuPAOXdMIC7xxRX5/QphdliqzOHdLODOofdEW4AEAjxxaCQWJy8TVj/ljzUPrsNQ5NcNQR+c2uIhj3Dq0qD407CziRsXiz7rlKq9xssMhZqMCpD6FrHdD41+Ako1Sjnyf8uRx81hPP/tTeQfQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741490523; c=relaxed/simple; bh=NhZ/S1hHipKSLMdNB94b5TfoRWwhK80Il9uh/3sM6Lw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ua1whFL5yZfR0+ynKU5LqIWaPXDsNZytaRROcsiYdhlvdSe3qMi7fbRhAI3aMQc4p836uDFotfXIBGrk+V+JD93WBWtct8PlsquOT/buH4Rye5U1BiRnlycE9cAaKl5gFqBxbiYCrw7QUsJGRGnDw0UBWJmQWX63aiyB1zD5W4s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net; spf=pass smtp.mailfrom=peff.net; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b=KCIiMSaW; arc=none smtp.client-ip=104.130.231.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peff.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peff.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peff.net header.i=@peff.net header.b="KCIiMSaW" Received: (qmail 5010 invoked by uid 109); 9 Mar 2025 03:22:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=peff.net; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; s=20240930; bh=NhZ/S1hHipKSLMdNB94b5TfoRWwhK80Il9uh/3sM6Lw=; b=KCIiMSaWl+LCrVZTQTxbvwlyu65v21AfZWRk0trFHRCRrSz96Ib2ovv2JYOfXojOcqskhX+Uq9R+Bh3IqoWwNDR5YpeoeX7iVJK8NINzbxtQDgj49MPKoeb0V8w3ae7MvE7a8VgfGyOwbqy8bxAlUHplLbw/oVtNQT8IQASdoebkMWmfIPZSEUt3JLMINAIhveCRMMySkiQ9nZyzLbidO01MILIJTXwrVg84xx5uhnmmZrc8nG73/s/eGUjT8gWsS3Er8D+a+88Gyg46RW4Rd1JJTFg/zfS8LuJyYjbvKeB4hLDkBEflIAm87ixWlkSnJCShgw0FtchU7Iu5zUxgdw== Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 09 Mar 2025 03:22:00 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 5116 invoked by uid 111); 9 Mar 2025 03:22:00 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 08 Mar 2025 22:22:00 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 8 Mar 2025 22:21:59 -0500 From: Jeff King To: Taylor Blau Cc: git@vger.kernel.org, Junio C Hamano , Igor Todorovski , Bence Ferdinandy Subject: [PATCH 9/9] fetch: use ref prefix list to skip ls-refs Message-ID: <20250309032159.GI2334191@coredump.intra.peff.net> References: <20250309030101.GA2334064@coredump.intra.peff.net> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250309030101.GA2334064@coredump.intra.peff.net> In git-fetch we have an optimization to avoid issuing an ls-refs command to the server if we don't care about the value of any refs (e.g., because we are fetching exact object ids), saving a round-trip to the server. This comes from e70a3030e7 (fetch: do not list refs if fetching only hashes, 2018-09-27). It uses an explicit flag "must_list_refs" to decide when we need to do so. That was needed back then, because the list of ref-prefixes was not always complete. If it was empty, it did not necessarily mean that we were not interested in any refs). But that is no longer the case; an empty list of prefixes means that we truly do not care about any refs. And so rather than an explicit flag, we can just check whether we are interested in any ref prefixes. This simplifies the code slightly, as there is now a single source of truth for the decision. It also fixes a bug in / optimizes a very unlikely case, which is: git fetch $remote ^foo $oid I.e., a negative refspec combined with an exact oid fetch. This is somewhat nonsense, in that there are no positive refspecs mentioning refs to countermand with the negative one. But we should be able to do this without issuing an ls-refs command (excluding "foo" from the empty set will obviously still be the empty set). However, the current code does not do so. The negative refspec is not counted as a noop in un-setting the must_list_refs flag (hardly the fault of e70a3030e7, as negative refspecs did not appear until much later). But by using the prefix list as a source of truth, this naturally just works; the negative refspec does not add a prefix to ask about, and hence does not trigger the ls-refs call. This is esoteric enough that I didn't bother adding a test. The real value here is in the code simplification. Signed-off-by: Jeff King --- builtin/fetch.c | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) diff --git a/builtin/fetch.c b/builtin/fetch.c index c26866e674..02af505469 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -1718,7 +1718,6 @@ static int do_fetch(struct transport *transport, const struct ref *remote_refs; struct transport_ls_refs_options transport_ls_refs_options = TRANSPORT_LS_REFS_OPTIONS_INIT; - int must_list_refs = 1; struct fetch_head fetch_head = { 0 }; struct strbuf err = STRBUF_INIT; @@ -1737,21 +1736,7 @@ static int do_fetch(struct transport *transport, } if (rs->nr) { - int i; - refspec_ref_prefixes(rs, &transport_ls_refs_options.ref_prefixes); - - /* - * We can avoid listing refs if all of them are exact - * OIDs - */ - must_list_refs = 0; - for (i = 0; i < rs->nr; i++) { - if (!rs->items[i].exact_sha1) { - must_list_refs = 1; - break; - } - } } else { struct branch *branch = branch_get(NULL); @@ -1776,18 +1761,20 @@ static int do_fetch(struct transport *transport, "HEAD"); } - if (tags == TAGS_SET || tags == TAGS_DEFAULT) { - must_list_refs = 1; + if (tags == TAGS_SET || tags == TAGS_DEFAULT) strvec_push(&transport_ls_refs_options.ref_prefixes, "refs/tags/"); - } - if (must_list_refs && + if (transport_ls_refs_options.ref_prefixes.nr && uses_remote_tracking(transport, rs)) strvec_push(&transport_ls_refs_options.ref_prefixes, "HEAD"); - if (must_list_refs) { + /* + * Only initiate ref listing if we have at least one ref we want to + * know about. + */ + if (transport_ls_refs_options.ref_prefixes.nr) { trace2_region_enter("fetch", "remote_refs", the_repository); remote_refs = transport_get_remote_refs(transport, &transport_ls_refs_options);