From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id cEr/HTLgz2HvQgEAgWs5BA (envelope-from ) for ; Sat, 01 Jan 2022 06:01:38 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id oF+8FjLgz2GnvgAAG6o9tA (envelope-from ) for ; Sat, 01 Jan 2022 06:01:38 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DF0AFEFE7 for ; Sat, 1 Jan 2022 06:01:37 +0100 (CET) Received: from localhost ([::1]:51664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3WWO-0000rg-TX for larch@yhetil.org; Sat, 01 Jan 2022 00:01:36 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33140) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3WW1-0000qx-On for guix-devel@gnu.org; Sat, 01 Jan 2022 00:01:15 -0500 Received: from world.peace.net ([64.112.178.59]:54834) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3WVz-0003Wy-Fc for guix-devel@gnu.org; Sat, 01 Jan 2022 00:01:13 -0500 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n3WVt-0002Es-7D; Sat, 01 Jan 2022 00:01:05 -0500 From: Mark H Weaver To: Liliana Marie Prikler , zimoun , guix-devel@gnu.org Subject: Re: On raw strings in commit field In-Reply-To: <762e9fb7116c442bf0f8f63221bf32fa2b77f2cf.camel@gmail.com> References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> <86y243kdoo.fsf@gmail.com> <899587fb6a76ddfa37d197d3d0fd23cdc7ad8592.camel@gmail.com> <867dbmi7pf.fsf@gmail.com> <3d448fe42f0c43574db96fa26aecd7da5fd5a95d.camel@gmail.com> <877dbkmjm9.fsf@netris.org> <762e9fb7116c442bf0f8f63221bf32fa2b77f2cf.camel@gmail.com> Date: Sat, 01 Jan 2022 00:00:26 -0500 Message-ID: <87y240kq2i.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=64.112.178.59; envelope-from=mhw@netris.org; helo=world.peace.net X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641013298; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=Smn4jTCbetejz5baut8YiGziSMrY8t5fTbLBDv7QYPc=; b=Ls43l4qV5m5r3MJ4X7Sul5RpJyaUa6Ngwa0WceCh9U+HQg/h101hvQBNEJDTIr8nYepT1i FebeeuTRI3MKu3zRjiW+eHPBM4fXbzaX0K+VfzuwAdUK5JsvWZgIRIcrcw8Zu2dZaH5fcR MSy6FrcDJ6mRDf/EZEgJJWZnmlFtsV5ef+NXL5qNWZeF8Rh8ciANlTWKUobtv8+rVXTWiN rPz6LDApM+Y+tsSKOvkucrIHaUL3x7c3IvFv0P6awV7w2MvvJmSGjxndp1QkakSt72a0fc Xn+9u8kAvcDDxcalEmOoFi50blIeXgPgA73XR10qdMWfcaJobfeHGT6ZLKs6fQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641013298; a=rsa-sha256; cv=none; b=UAi7Y/JHmr2niWhiuiJQymxU7GPEbfrOJArdzLF+Xcz7e/N3pjyP2slCgfLJ6ZTvZHrevU 0xNp4Kiz1Qq70Hvy45O3Nr1+epZYDs1ge3L69FWwg9v7GNT7BxGXOMCkMHoklGTLCkMjLz EagcPMRaVz31Aj1+vHPr+x7jP8vPWEXkPEYGZnFGpd2QMy2/gqWBKxXKvLiKFN9WWv1mf0 7MaZ+1opLwKLfbiUg99vP2g2mAyvdYpJAoFZf7i85V02yO80I27FnqdgMf5I8OQZ+0+HGO MmMmcsezS2yCBJUuYjAB2wyBAvu6aJfmr6epC20qtQiAZ4XNlI/K1BpQMvb57A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.08 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: DF0AFEFE7 X-Spam-Score: -3.08 X-Migadu-Scanner: scn1.migadu.com X-TUID: ZevNa2kYnrvn Hi Liliana, Liliana Marie Prikler writes: > Am Freitag, dem 31.12.2021 um 18:36 -0500 schrieb Mark H Weaver: >> Hi Liliana, >>=20 >> Liliana Marie Prikler writes: >> > In my personal opinion, the version+raw commit style can be >> > discredited using Cantor's diagonal argument. >>=20 >> You've mentioned Cantor's diagonalization argument at least twice in >> this thread so far, but although I'm familiar with that kind of >> argument for showing that certain sets are uncountable, I don't >> understand how it applies here.=C2=A0 Can you please elaborate? > Okay, so let's write out the full argument. At a certain date, we > package or update P to version V through reference to tag T (at commit > C). Because we can't trust T to remain valid, we only keep (V, C) > around for "robustness". > > Now notice, how version V is generated by referring to T. Without loss > of generality, assume that T is invalidated, otherwise nothing to > prove. Since V is created through reference to T, it is also > invalidated as being the canonical V, whichever it is. A similar > argument can be made for C as well. So both (V, C) are invalidated and > the only thing we can claim is "yeah, upstream did tag that T at some > point". > > Let us now assume, that T is never invalidated. In this case (V, C) > remain robust for all observable time, but so would (V, T). Hence > there is no robustness to be gained in this scenario. > > Now what if we were to instead define V' :=3D (B, N, C') with N being a > number to order the different Cs under B and C' being the first few > bytes of C. Since V' clearly points to C, there is a clear link > established between the two even if T is lost at some point and we > coincidentally have B :=3D clean(T) for some cleaning function clean. > > Now obviously V' is exactly what git-version does and there are some > problems with it if we move back to the real world. For one, I don't > think our updater would currently detect that upstream moved T to a > newer commit, whereas using tag for commit makes us notice breakages > loudly (too loudly as some argue, hence the move away from it).=20 > However, since I'm a "people first, machines second" girl, I am willing > to ignore this minor inconvenience and take the robustness if that's > the extent of the issues it brings. > > To state something that probably hasn't gotten enough attention here, > my main problem is not that we are adding robustness by using commits > in the commit field more often, my problem is that we're using raw > commits when the version field would suggest we're using a tag. One > could raise the issue that long versions would become unreadable and > this is largely a non-issue on the command line, but assuming that it > is, I did provide other potential solutions. > > So the main question here is: Do we really want raw strings in the > commit field? Is there no better way of providing "robustness"? Where is the Cantor-style diagonalization argument that you spoke of? Regards, Mark --=20 Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about .