From patchwork Wed Nov 29 08:14:07 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Steinhardt X-Patchwork-Id: 13472393 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pks.im header.i=@pks.im header.b="BYX5S+CA"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="HpiwY35z" Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F49A172E for ; Wed, 29 Nov 2023 00:14:13 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 75EB95C0213; Wed, 29 Nov 2023 03:14:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 29 Nov 2023 03:14:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm1; t=1701245652; x=1701332052; bh=Pn/SlI4zTXS1A7eosTrDqlte7 bieOnW83fkgMdhNQ5k=; b=BYX5S+CAA8bkk9+GviplBLZd/VDi6W02rw0KXj1NY etPfMOMvhDOwMVegObrrMiICVtdIo73CdenIFKREOG5meq56t3Cnc1HC7J4I8WnM NQ+0Czn1ipECuK5mdFMJXFhFRzGCFY2Chvq6X8VuMBS6Cup+FBYOBqwChsZQgGj9 JEgVWHnFa7sRr9+UiMmQVgwDFI5JLJCOymt3Cba4wMf3W3PQrxkQsr71jN67ipHT MskNMXeYYLR+lzcqQRqFG7GQKR+WfSnt2CygJkzT3s4tNWbT1Gwp7+Ar8XasShy/ +W8bcGU48ViuBgRF9WW+RESs/EuOuvyupeUGxgy1/jWvg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1701245652; x=1701332052; bh=Pn/SlI4zTXS1A7eosTrDqlte7bieOnW83fk gMdhNQ5k=; b=HpiwY35zW/ezs9bWSh6eFhB6yx1MfOQ2WDY3vqfoRh6pWJHnpeA Iqd04pPXdyTZWHvC7mkX1FS0Tx7vdmpLhgLprsibEq+fLl1Mx9CnHyezEoko78Sy PUrTU72pogCb0f+gZ4zK6TdjUzM3fU3reRNcBRe+OFZucSi6/7zmV6kvC2B5pUgr oahtT7zJxoA2kgipKXe66sUzGcT/4dXKuyu0EUvraaoyy6V1vQLYk+liU3Yp7v8n InSPuhTFGAkxYtr/sIgher+rWkJ5Oz0hLArgyvFcJuVj98kViD+WACCQAC119Ypj ivfqLHMR1nZS7CR33CW+CB6BdgmRhoPpLPQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeigedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkgggtugesghdtre ertddtvdenucfhrhhomheprfgrthhrihgtkhcuufhtvghinhhhrghrughtuceophhssehp khhsrdhimheqnecuggftrfgrthhtvghrnhepuefguedtueeiheetleevgedujeekjeehle ejjefhhffghfevgfekueekjedtieejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepphhssehpkhhsrdhimh X-ME-Proxy: Feedback-ID: i197146af:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 29 Nov 2023 03:14:11 -0500 (EST) Received: by vm-mail (OpenSMTPD) with ESMTPSA id 53f5895f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 29 Nov 2023 08:12:59 +0000 (UTC) Date: Wed, 29 Nov 2023 09:14:07 +0100 From: Patrick Steinhardt To: git@vger.kernel.org Cc: hanwenn@gmail.com Subject: [PATCH 0/4] refs: improve handling of special refs Message-ID: Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Hi, there are a bunch of "special" refs in Git that sometimes behave like a normal reference and sometimes they don't. These references are written to directly via the filesystem without going through the reference backend, but the expectation is that those references can then be read by things like git-rev-parse(1). We do not currently have a single source of truth for what those special refs are, and we also don't have clear rules for how they should be written to. This works in the context of the files backend, because it is able to read back such manually-written loose references just fine. But once the reftable backend lands this will stop working. This patch series tries to improve this state by doing two things: 1. We explicitly mark these references as special by introducing a new `is_special_ref()` function. This serves as documentation, but will also cause us to explicitly read all of these special refs via loose files regardless of the actual backend. 2. We document a new rule around writing refs. Namely, normal references are _always_ written via the reference backend, whereas special references are _always_ written directly via the filesystem. This rule is not enforced anywhere, but at least it's now made more explicit. The last patch fixes one of the instances where we treat a reference inconsistently by converting it to a normal reference. We can eventually migrate more of the special refs to become normal refs as we deem fit, but I consider this to be out of scope for this patch series. These patches improve compatibility with the new reftable backend. Patrick Patrick Steinhardt (4): wt-status: read HEAD and ORIG_HEAD via the refdb refs: propagate errno when reading special refs fails refs: complete list of special refs bisect: consistently write BISECT_EXPECTED_REV via the refdb bisect.c | 25 +++------------ builtin/bisect.c | 8 ++--- refs.c | 64 +++++++++++++++++++++++++++++++++++-- t/t1403-show-ref.sh | 9 ++++++ t/t6030-bisect-porcelain.sh | 2 +- wt-status.c | 17 +++++----- 6 files changed, 86 insertions(+), 39 deletions(-)