From: Mark H Weaver <mhw@netris.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>,
zimoun <zimon.toutoune@gmail.com>,
guix-devel@gnu.org
Subject: Re: On raw strings in <origin> commit field
Date: Sat, 01 Jan 2022 00:00:26 -0500 [thread overview]
Message-ID: <87y240kq2i.fsf@netris.org> (raw)
In-Reply-To: <762e9fb7116c442bf0f8f63221bf32fa2b77f2cf.camel@gmail.com>
Hi Liliana,
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> Am Freitag, dem 31.12.2021 um 18:36 -0500 schrieb Mark H Weaver:
>> Hi Liliana,
>>
>> Liliana Marie Prikler <liliana.prikler@gmail.com> 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"?
Where is the Cantor-style diagonalization argument that you spoke of?
Regards,
Mark
--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>.
next prev parent reply other threads:[~2022-01-01 5:01 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-28 20:55 On raw strings in <origin> commit field Liliana Marie Prikler
2021-12-29 8:39 ` zimoun
2021-12-29 20:25 ` Liliana Marie Prikler
2021-12-30 12:43 ` zimoun
2021-12-31 0:02 ` Liliana Marie Prikler
2021-12-31 1:23 ` zimoun
2021-12-31 3:27 ` Liliana Marie Prikler
2021-12-31 9:31 ` Ricardo Wurmus
2021-12-31 11:07 ` Liliana Marie Prikler
2021-12-31 12:31 ` Ricardo Wurmus
2021-12-31 13:18 ` Liliana Marie Prikler
2021-12-31 13:15 ` zimoun
2021-12-31 15:19 ` Liliana Marie Prikler
2021-12-31 17:21 ` zimoun
2021-12-31 20:52 ` Liliana Marie Prikler
2021-12-31 23:36 ` Mark H Weaver
2022-01-01 1:33 ` Liliana Marie Prikler
2022-01-01 5:00 ` Mark H Weaver [this message]
2022-01-01 10:33 ` Liliana Marie Prikler
2022-01-01 20:37 ` Mark H Weaver
2022-01-01 22:55 ` Liliana Marie Prikler
2022-01-02 22:57 ` Mark H Weaver
2022-01-03 21:25 ` Liliana Marie Prikler
2022-01-03 23:14 ` Mark H Weaver
2022-01-04 19:55 ` Liliana Marie Prikler
2022-01-04 23:42 ` Mark H Weaver
2022-01-05 9:28 ` Mark H Weaver
2022-01-05 20:43 ` Liliana Marie Prikler
2022-01-06 10:38 ` Mark H Weaver
2022-01-06 11:25 ` Liliana Marie Prikler
2022-01-02 19:30 ` zimoun
2022-01-02 21:35 ` Liliana Marie Prikler
2022-01-03 9:22 ` zimoun
2022-01-03 18:13 ` Liliana Marie Prikler
2022-01-03 19:07 ` zimoun
2022-01-03 20:19 ` Liliana Marie Prikler
2022-01-03 23:00 ` zimoun
2022-01-04 5:23 ` Liliana Marie Prikler
2022-01-04 8:51 ` zimoun
2022-01-04 13:15 ` zimoun
2022-01-04 19:45 ` Liliana Marie Prikler
2022-01-04 19:53 ` zimoun
2021-12-31 23:56 ` Mark H Weaver
2022-01-01 0:15 ` Liliana Marie Prikler
2021-12-30 1:13 ` Mark H Weaver
2021-12-30 12:56 ` zimoun
2021-12-31 3:15 ` Liliana Marie Prikler
2021-12-31 7:57 ` Taylan Kammer
2021-12-31 10:55 ` Liliana Marie Prikler
2022-01-01 1:41 ` Mark H Weaver
2022-01-01 11:12 ` Liliana Marie Prikler
2022-01-01 17:45 ` Timothy Sample
2022-01-01 19:52 ` Liliana Marie Prikler
2022-01-02 23:00 ` Timothy Sample
2022-01-03 15:46 ` Ludovic Courtès
2022-01-01 20:19 ` Mark H Weaver
2022-01-01 23:20 ` Liliana Marie Prikler
2022-01-02 12:25 ` Mark H Weaver
2022-01-02 14:09 ` Liliana Marie Prikler
2022-01-02 2:07 ` Bengt Richter
2021-12-31 17:56 ` Vagrant Cascadian
2022-01-03 15:51 ` Ludovic Courtès
2022-01-03 16:29 ` Vagrant Cascadian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y240kq2i.fsf@netris.org \
--to=mhw@netris.org \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@gmail.com \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).