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: AS54825 139.178.88.0/22 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 sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99]) (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 8E0291F44D for ; Mon, 1 Apr 2024 16:17:54 +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=L+3S9w6t; 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 51F8E284B83 for ; Mon, 1 Apr 2024 16:17:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E05C547A7C; Mon, 1 Apr 2024 16:17:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="L+3S9w6t" 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 3656847A57 for ; Mon, 1 Apr 2024 16:17:47 +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=1711988268; cv=none; b=Q2Va+S6asSxr9GLJhb9T6WV7ocjy0XylBw3gdQG6jUcDwV8sNXe50dtwxW2NzivbxT+71u15xDRq85IPIshuoprOeuV05/MJ9Mf6FTnG95SxsummZYsz4o+6qjYK/zr4xLVUnWDtDcGaOM7J0vB+cg/U0OZYRy8fa1f9dOdzsAo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711988268; c=relaxed/simple; bh=Oc2YEs5inPtSZHWmuzSBMPtY6euVdJjX0H9wXpJJjZI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=UB4N9QAojSSG9WbZ6U+Y+7GYTtcbuDM/MK6kyReRN/7NZwtdRIlhqEKrMnrXoC1GJMcHC8KEun75jmW8gJiUfvXOxyvZjO6YmUhyNjDkYMebQ5oUB4P4fqThpYnx/TE3EzIiV+c8nFv/7BnrBmx/gWS0Vb9OfQYP95enHWRVAtg= 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=L+3S9w6t; 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 88AC21D456; Mon, 1 Apr 2024 12:17:46 -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=Oc2YEs5inPtSZHWmuzSBMPtY6euVdJjX0H9wXp JJjZI=; b=L+3S9w6tXp0KNH9sHzYNtKTnp72NG5k61aNpNPQxhJm3uqE2qmbpKt PDjumoioGRmQiGoqFFI+KHrylrba3gdqQYZvjgSHBspUU3oBRp/I/d/Mo6fngxIj kZO+tmV5A9E2NVmDCKERrudHq92d6UE2PN+edZa/vr8ySMYoS0Brw= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 805EC1D455; Mon, 1 Apr 2024 12:17:46 -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 D932D1D451; Mon, 1 Apr 2024 12:17:42 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Karthik Nayak Cc: git@vger.kernel.org, ps@pks.im Subject: Re: [PATCH 7/8] refs: add 'update-symref' command to 'update-ref' In-Reply-To: (Karthik Nayak's message of "Mon, 1 Apr 2024 04:48:02 -0700") References: <20240330224623.579457-1-knayak@gitlab.com> <20240330224623.579457-8-knayak@gitlab.com> Date: Mon, 01 Apr 2024 09:17:41 -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: 5E3480A0-F043-11EE-91BF-A19503B9AAD1-77302942!pb-smtp21.pobox.com Karthik Nayak writes: >> 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. Note that I did not (and do not) know if "create" and "delete" have such checks; I expected somebody (other than me) to check before going forward. > But this still means we need to think of the best output for the > reference transaction hook (following commit). > > My current implementation of: > SP LF > Should be changed to: > SP LF > > But this means, for creation of symrefs needs to be "zero" > value. Also there is no way for clients to differentiate between regular > refs and symrefs here. I wonder if it makes sense to do something like: > > symref SP SP LF What do clients see for a regular ref? " SP LF"? That would be OK, as "symref" cannot be an object name, I guess? > Where symref is a fixed string at the start, used as a differentiator. > This however still would leave us to deal with "zero" values for > creation and deletion. Are these two and values optional in the context of your discussion? The review comment was on input from the end-user that made it optional to validate the precondition, but this is what you produce as a result---if these are not optional, then an empty string can be a reasonable "zero" value. I am confused... > Perhaps the best way here to actually be a lot more verbose and have the > hook output the following: > > symref-create SP LF > symref-delete SP LF > symref-update SP SP LF > symref-update-forced LF It is unfortunate that the input to the hook for a normal reference update uses syntax different from the "--stdin" input format, i.e., SP SP LF but it is way too late to change it now. So to be consistent, symref-create SP SP LF symref-delete SP SP LF symref-update SP SP SP LF would be the three operations. But this is not an end-user input that tells Git "I do not care about precondition, I did not even bother to learn the current state to give you as , just force it". The input to hook is what we tell the hook what we are planning to do (so that it can decline), and we do not need the ability to say "I do not know what the current state is". So I do not think you need any "zero" value in the input to the reference-transaction hook. And I do not see a need for the "symref-update-forced" variant, either. By the way, if we were to use symref-{create,delete,update} here, wouldn't it make more sense to name the command on the "--stdin" side the same, i.e., not "update-symref" but "symref-update"? What I suspect that needs more thought is what should happen when you request via "--stdin" to create, update, or delete a symref, but is a regular ref, e.g., "symref-delete ". For "symref-create ", we would fail if exists, whether it is a symref or a normal ref, so that is OK. For "symref-delete ", we would fail if is *not* a symref to , so the case where is a normal ref is already covered. Should we support "symref-update " that makes a symref that points at , but ensures that before the operation is a normal ref that points at ? Or should "symref-update" work only on that is an existing symref? I think I am OK if the answer was "You can only give a precondition in the form of , which means you can only turn an existing symref to point at a different ref with precondition protection. If you want to turn a normal ref into a symref, you have to force it by not having a precondition, or delete the ref and then (re)create it as a symref". But we need to decide the semantics and document it. Thanks.