From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6K1YOWqvz2E/PQAAgWs5BA (envelope-from ) for ; Sat, 01 Jan 2022 02:33:30 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 6MsAMmqvz2FfgAAAG6o9tA (envelope-from ) for ; Sat, 01 Jan 2022 02:33:30 +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 61D7DC65B for ; Sat, 1 Jan 2022 02:33:30 +0100 (CET) Received: from localhost ([::1]:54356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3TGz-0007VI-F2 for larch@yhetil.org; Fri, 31 Dec 2021 20:33:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41340) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3TGo-0007V9-H8 for guix-devel@gnu.org; Fri, 31 Dec 2021 20:33:18 -0500 Received: from [2a00:1450:4864:20::344] (port=54154 helo=mail-wm1-x344.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n3TGm-0008VK-Tz for guix-devel@gnu.org; Fri, 31 Dec 2021 20:33:18 -0500 Received: by mail-wm1-x344.google.com with SMTP id l4so18098859wmq.3 for ; Fri, 31 Dec 2021 17:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=N5HdXVCXT+esHI0yQmFZC9JB0LaPygLVe1wTHKujHP4=; b=cTsxKGjta5dmwt5LrfWAE0rKyUJctn/EODUHyHbjJ6hdT3IVWDkosciaX0W2oJ94m5 xOl72qi4uChf+sDRPllejBW38zfuCjdRop9ZFDydI1WxZIwhH0JE0EbOdFuIt+ZYvBqw BRpSbkdf61lusVBQ74D7FmGk3R5Hn86obGqDZAhE5Skubv6Ska1tvvbtPeonFTQ/9nN0 w4tP5Emmovplkl9nchqbW08QYb+X2mc20yryl+2biGOT3tB3vcNMkKwFvyQaisSzhmLR C2E2VFHAkV8Mq9oiIwfwi6tviwn66+ybQ6TEsuq18xmAIfIJd3KAqp3tck6elmkHvqLB s1eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=N5HdXVCXT+esHI0yQmFZC9JB0LaPygLVe1wTHKujHP4=; b=DSP8gkCOb7bz5Ys+zYrkX/mSMtv8rv56QB4VrZqjY+IKaLSQ15P0Pz0qpK7VtBYFhE XKjybZsjesUYIOyzleRP9xg8KITMN8orTisaKUNnWqxj2dbJHMHqL/gS/z1DHdULx7Kw 6dQj92crrRqcK3VtPuhgzx1wB1TAJFNk3EXkK6qldLvHnb9mIY4tdEiAq6MCRsKDsghE glEihe0S6VZb/2l/KIsNVkbqeQLhCzkkG7gBFYE6LVGdlq1/6fGFiiHo+jq+hnHsg8Qa XyMYTrO1eVULauES9OkabPgN7YxRZt0sqUwsHf39TPQnAy7OKIOUKoV4utaxEIUi/RN+ zD6A== X-Gm-Message-State: AOAM532ZmbpSsECVUFFLblfuya3B5Xm7UJfgOjM0jstZQxwIq6r7PATk XQ1GJLGw7/ocMo+Nm1ma3fo= X-Google-Smtp-Source: ABdhPJzpbK7p4e2OYDi+I3/kmXtnrdcMGhR64IaYGO6APDXEMzvW6EiacPsvb+O1CZkuBxcyMpQzHw== X-Received: by 2002:a05:600c:4f91:: with SMTP id n17mr28252300wmq.195.1641000795357; Fri, 31 Dec 2021 17:33:15 -0800 (PST) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id d22sm27916408wmq.17.2021.12.31.17.33.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Dec 2021 17:33:14 -0800 (PST) Message-ID: <762e9fb7116c442bf0f8f63221bf32fa2b77f2cf.camel@gmail.com> Subject: Re: On raw strings in commit field From: Liliana Marie Prikler To: Mark H Weaver , zimoun , guix-devel@gnu.org Date: Sat, 01 Jan 2022 02:33:13 +0100 In-Reply-To: <877dbkmjm9.fsf@netris.org> 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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::344 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::344; envelope-from=liliana.prikler@gmail.com; helo=mail-wm1-x344.google.com X-Spam_score_int: 6 X-Spam_score: 0.6 X-Spam_bar: / X-Spam_report: (0.6 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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=1641000810; 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:dkim-signature; bh=N5HdXVCXT+esHI0yQmFZC9JB0LaPygLVe1wTHKujHP4=; b=T/YhzzEYnjdT3EFb5VFl2C3pSRuqsq7cwZG/ZfWgbGiusA+07uG2dRlOqdMx9kOfZ0vWUC Nt0zhUn35fK8siTUGcxWb3jZr2Tcdu8LJ7DstO8mH5BEqFSxhMEkDuIwoTp2siM2T+UNTm L+isn2H9H8XApWy0eb2UI2NvfcHYbqjvDuekyhwQpq1mzsC7XeGaxFrhWDZbhJHMPCZUZd yTU2WCdH2uzyoCOgKWiktfTjlmpB7F9BkzcHcbwdhmG2ja0hQneJLWxccfHSjo/S4n2sFK H/E6DcnMagEYrCis4O8EmhBXl0sQBet2B6dRmCSEiTyL0QZz6THbCH1ckchG/g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641000810; a=rsa-sha256; cv=none; b=X2nRDAqlGMAGn2tTRvXPfkw1lmy8HmfDPDqTK8oCUTr34tT/Z1+y5T4IwH8y3SHUFAH/lO AgFuBI4mLtjct9k6U9i26qsB9jj3terevwqdMPnvV91FTyCACC9EWStRXygRWEStVXuQlI Vist3akdp4ZmpKONQ9DK2zswRMLdLBEdeo49HTKpabm2oX9yNA6rQ9C3RP/pOcKazDsBmI lYw2FVIh149CnkOZQ8E4OOFUHGLTiVmQFzL3IwZpWxOeXP0phbn/dYXmIiU25OvXtFhrq2 Lxkf14rES/ciYSNXtHdAC4WfsZWS3sIYyLxLcu7idK9uK1RSWYeMwgbHWbsafQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cTsxKGjt; dmarc=pass (policy=none) header.from=gmail.com; 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: -4.28 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cTsxKGjt; dmarc=pass (policy=none) header.from=gmail.com; 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: 61D7DC65B X-Spam-Score: -4.28 X-Migadu-Scanner: scn1.migadu.com X-TUID: 47t/i2JaT6DF Am Freitag, dem 31.12.2021 um 18:36 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > In my personal opinion, the version+raw commit style can be > > discredited using Cantor's diagonal argument. > > 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.  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' := (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 := 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). 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"?