From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [IPv6:2604:1380:4601:e00::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2FDBF1F44D for ; Mon, 1 Apr 2024 01:31:46 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=pobox.com header.i=@pobox.com header.a=rsa-sha256 header.s=sasl header.b=ai9/ajeN; dkim-atps=neutral Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id DB25B1F21976 for ; Mon, 1 Apr 2024 01:31:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 41B414A1B; Mon, 1 Apr 2024 01:31:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="ai9/ajeN" Received: from pb-smtp21.pobox.com (pb-smtp21.pobox.com [173.228.157.53]) (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 98105A55 for ; Mon, 1 Apr 2024 01:31:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=173.228.157.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711935080; cv=none; b=jSJFf1ps0ljt3NZtb2k5YqGE1PLMAak1j66r6OIyGnqWNSNX/GJxPUeYo0nvwuDh0kicM0LbMmTMW5F9gAXRBiBoZpDBchLFe+/Ihy5XGW/XDGSmp+aXGnKGiTAR+5v01J1+1oI+MtjsZTbr6ckUX/noG/S1Z1d/hfCG67Ttqo0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711935080; c=relaxed/simple; bh=pXScDT/i0BlWtAMbBARK/W7KH7HVdPD7srwke/NhEaU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=q9J+HzYU+Lm89KBCCZbMZC/b4tTa9pIJj9orTaFc0x1QnwsyL3kIuKwEfWLAsqijm7gAuIO7YJLKHOGfMweNntWnI8id7BJXD+dn/hsBam71XkRFLGtoLl4uMEUg1XYWbChV94D5k2zajR3lo90X+lC8I7mBvTvxnIPRBR9ufMk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=pobox.com; spf=pass smtp.mailfrom=pobox.com; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b=ai9/ajeN; arc=none smtp.client-ip=173.228.157.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=pobox.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pobox.com Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 297DA1862D; Sun, 31 Mar 2024 21:31:19 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:in-reply-to:references:date:message-id:mime-version :content-type; s=sasl; bh=pXScDT/i0BlWtAMbBARK/W7KH7HVdPD7srwke/ NhEaU=; b=ai9/ajeN769yCKapCNhp8iDGTCkR2pMTqGX1nBxS1ro3q5N1ORJcIQ Dimxs6bembEgTUa4Pj0wWJFMqyIFUT8nkfx/XoeLjwtiBmQCJVBQsnepNZCejBcc Zr0xYPb+12BPDhQori02Ddt4rMVL71m6HwsyHhWR0pkMcw6Px387Y= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 215551862C; Sun, 31 Mar 2024 21:31:19 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.125.139.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 9D0E41862B; Sun, 31 Mar 2024 21:31:15 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Chris Torek Cc: Karthik Nayak , git@vger.kernel.org, ps@pks.im Subject: Re: [PATCH 7/8] refs: add 'update-symref' command to 'update-ref' In-Reply-To: (Junio C. Hamano's message of "Sun, 31 Mar 2024 16:14:21 -0700") References: <20240330224623.579457-1-knayak@gitlab.com> <20240330224623.579457-8-knayak@gitlab.com> Date: Sun, 31 Mar 2024 18:31:14 -0700 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 8822E144-EFC7-11EE-B3C8-A19503B9AAD1-77302942!pb-smtp21.pobox.com Junio C Hamano writes: > Chris Torek writes: > >> For these reasons, I'd suggest that the all-zero hash be officially >> deprecated in favor of create/delete and of course create-symref >> and delete-symref. Of course, compatibility requires some sort >> of support for the old system for some time. As to whether that >> means something like the suggestion of ".missing" etc, I have no >> particular opinion -- but since the symref options are new, they >> would not *need* symmetric options, if we just say that "update-symref" >> cannot create or delete a symref. > > I love that simplicity. Having said that, the loose "update that can create or delete" may actually be used by applications that do not care about overwriting competing operation, so I am not sure if we can easily deprecate that mode of operation. Saying "update refs/heads/next to point at this object" and have it created if it does not exist may be handy for some loosely written applications. So perhaps we can say "update with a concrete will ensure that the poitns at before proceeding, but update with 0{40} as to ensure creation is deprecated. update with 0{40} as as deletion is also deprecated. Use create and delete for these two deprecated operation modes". This assumes that create and delete currently ensures that what is asked to be created does not exist, and what is asked to be deleted does exist, before the operation. If we are loosely doing these two operations, then we cannot easily deprecate the checking-update, without breaking existing users. As {create,update,delete,verify}-symref do not exist yet, we can start with the right semantics from day one. "update-symref" will accept a only to ensure that the symref is pointing to that ref and there is no "zero" value based creation/deletion validation offered via "update-symref". "create-symref" will error out if the ref asked to be created already exists, "delete-symref" will error out if the ref asked to be deleted does not exist.