Re: On raw strings in commit field

Hi, Am Donnerstag, dem 06.01.2022 um 05:38 -0500 schrieb Mark H Weaver: > > From here on, I will assume that each individual push action is > > finite as you did, but I don't think that using communications of > > finite length are a helpful building block here. > > Really?  You don't think

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > it ought to have been comparatively easy to infer that I was talking > about push actions (plural) as sequences, not as individual push > actions like you've used for your proof. It makes no difference, because the set of push actions is closed under

Re: On raw strings in commit field

Am Mittwoch, dem 05.01.2022 um 04:28 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Earlier, I wrote: > > Sorry, but this is not even close to a valid argument that the set > > of possible push actions to a Git repo is uncountable.  In fact, > > it's quite easy to prove that the set is countable. 

Re: On raw strings in commit field

Hi Liliana, Earlier, I wrote: > Sorry, but this is not even close to a valid argument that the set of > possible push actions to a Git repo is uncountable. In fact, it's quite > easy to prove that the set is countable. Any mathematician will know this. I suppose I should give a proof. I'll

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Montag, dem 03.01.2022 um 18:14 -0500 schrieb Mark H Weaver: >> >> > If you are talking specifically about the uncountability of real >> > numbers, that'd be quite deep down (as in an uncountability of push >> > actions to a particular Git repo,

Re: On raw strings in commit field

Am Montag, dem 03.01.2022 um 18:14 -0500 schrieb Mark H Weaver: > > > If you are talking specifically about the uncountability of real > > numbers, that'd be quite deep down (as in an uncountability of push > > actions to a particular Git repo, particularly if we also allow > > reinitialization).

Re: On raw strings in commit field

Hi Liliana, On Tue, 4 Jan 2022 at 20:45, Liliana Marie Prikler wrote: > I don't think there's anything to see here. Believe it or not, but > you've so far been boiling my water multiple times only to then throw > it into my face as I attempt to put the rice in. Admittedly, that's a > little

Re: On raw strings in commit field

Hi simon, > Please re-read all your answers and mines. I hope you will see where > you were incorrect. I don't think there's anything to see here. Believe it or not, but you've so far been boiling my water multiple times only to then throw it into my face as I attempt to put the rice in.

Re: On raw strings in commit field

Hi Liliana, On Tue, 04 Jan 2022 at 09:51, zimoun wrote: > On Tue, 04 Jan 2022 at 06:23, Liliana Marie Prikler > wrote: > >>> The content can be one file, some files, folders, etc.  or Git >>> objects as Git commit object or Git tree object or whatever.  >>> Therefore, Git commit hash only

Re: On raw strings in commit field

On Tue, 04 Jan 2022 at 06:23, Liliana Marie Prikler wrote: >> The content can be one file, some files, folders, etc.  or Git >> objects as Git commit object or Git tree object or whatever.  >> Therefore, Git commit hash only depends on the content itself, i.e., >> Git commit object; as

Re: On raw strings in commit field

Hi simon, Am Dienstag, dem 04.01.2022 um 00:00 +0100 schrieb zimoun: > [...] > > You are saying what I predicted you will say :-) ; here I quote > myself: > >     The statement «Git commit hashes do not just depend on the >     content» is wrong.  [...] > > Sorry, I used meta-content

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Sonntag, dem 02.01.2022 um 17:57 -0500 schrieb Mark H Weaver: >> Hi Liliana, >> >> Liliana Marie Prikler writes: >> >> > Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver: >> > > Liliana Marie Prikler writes: >> > > > > Where is

Re: On raw strings in commit field

Hi Liliana, On Mon, 03 Jan 2022 at 21:19, Liliana Marie Prikler wrote: > That's not the case I'm making here. The case I'm making is that Git > considers some content content, which Guix does not consider content. > If I push the same file to two branches, once with the commit message >

Re: On raw strings in commit field

Am Sonntag, dem 02.01.2022 um 17:57 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > > Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver: > > > Liliana Marie Prikler writes: > > > > > Where is the Cantor-style diagonalization argument that you > >

Re: On raw strings in commit field

Am Montag, dem 03.01.2022 um 20:07 +0100 schrieb zimoun: > This is somehow intrinsic* because public-inbox uses Message-ID as URL. > Therefore, using emacs-notmuch, you just have to search for > id:86y243kdoo@gmail.com for instance. > > *intrinsic: no it is not intrinsic but self-contained.

Re: On raw strings in commit field

Hi Liliana, On Mon, 03 Jan 2022 at 19:13, Liliana Marie Prikler wrote: > Am Montag, dem 03.01.2022 um 10:22 +0100 schrieb zimoun: >> On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler >> wrote: >> >> > > The statement still appears to me wrong because Git commit hash >> > > only depends on

Re: On raw strings in commit field

Am Montag, dem 03.01.2022 um 10:22 +0100 schrieb zimoun: > Hi Liliana, > > On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler > wrote: > > > > The statement still appears to me wrong because Git commit hash > > > only depends on the content itself. > > > > If you define content through the

Re: On raw strings in commit field

On 2022-01-03, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> How about using the output of git describe, which can unambigously >> include the most relevent tag, the number of commits since that tag, and >> the commit hash: >> >> $ git describe --long --abbrev=41 >>

Re: On raw strings in commit field

Hello, Vagrant Cascadian skribis: > How about using the output of git describe, which can unambigously > include the most relevent tag, the number of commits since that tag, and > the commit hash: > > $ git describe --long --abbrev=41 > v1.3.0-13278-g60661adfb8ffa28e1acfcfea27c6cc2fc70f88fe

Re: On raw strings in commit field

Hello! Timothy Sample skribis: > If you want a concrete example to think through, there’s ‘eclib’. Our > package says it’s version “20190909”, but that’s not what upstream calls > version “20190909”. It looks like when we packaged ‘eclib’, that tag > pointed to commit

Re: On raw strings in commit field

Hi Liliana, On Sun, 02 Jan 2022 at 22:35, Liliana Marie Prikler wrote: >> The statement still appears to me wrong because Git commit hash only >> depends on the content itself. > > If you define content through the NAR hash used by Guix, I'm pretty > sure vanity commits invalidate that

Re: On raw strings in commit field

Hey, Liliana Marie Prikler writes: > Since you are our expert on preservation, would you mind if I ask you > for some estimates on how painful it is to track down such commits in > general, if it could be made easier were you to record tag → commit > (alternatively file-name x sha256 → SWHID)

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver: >> Liliana Marie Prikler writes: >> >> > > Where is the Cantor-style diagonalization argument that you spoke >> > > of? >> > You skipped over it, read again.  The key point is that

Re: On raw strings in commit field

Hi Simon, Am Sonntag, dem 02.01.2022 um 20:30 +0100 schrieb zimoun: > Last on this point, using ’git-version’ and commit or tag to define > Guix version (the field ’version’) is not related to the issue of > referring by tag or commit in ’uri’ field.  That’s not the same > level. Look at the

Re: On raw strings in commit field

Hi Mark, Liliana, all, On Sat, 01 Jan 2022 at 15:37, Mark H Weaver wrote: >>> Where is the Cantor-style diagonalization argument that you spoke of? >> >> You skipped over it, read again. The key point is that you're >> referencing the thing you think will be invalidated to create your >>

Re: On raw strings in commit field

Hi Mark, Am Sonntag, dem 02.01.2022 um 07:25 -0500 schrieb Mark H Weaver: > Repeating myself: our difficulties understanding each other on this > point might be due a translation issue.  Earlier, you wrote: > > > And here I disagree.  This reasoning presupposes that we have to > > ensure that

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Samstag, dem 01.01.2022 um 15:19 -0500 schrieb Mark H Weaver: >> Hi Liliana, >> >> Liliana Marie Prikler writes: >> >> > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: >> > > I disagree with the last line above.  What makes you

Re: On raw strings in commit field

[0] https://cdn.quotesgram.com/img/31/40/532049644-676813c5150a0168ad089c40202f742e.jpg On +2022-01-01 12:12:33 +0100, Liliana Marie Prikler wrote: > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: > > I disagree with the last line above.  What makes you think that I'm > >

Re: On raw strings in commit field

Hi, Am Samstag, dem 01.01.2022 um 15:19 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: > > > I disagree with the last line above.  What makes you think that > > > I'm presupposing that the tag

Re: On raw strings in commit field

Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver: > Liliana Marie Prikler writes: > > > > Where is the Cantor-style diagonalization argument that you spoke > > > of? > > You skipped over it, read again.  The key point is that you're > > referencing the thing you think will be

Re: On raw strings in commit field

Liliana Marie Prikler writes: >> Where is the Cantor-style diagonalization argument that you spoke of? > You skipped over it, read again. The key point is that you're > referencing the thing you think will be invalidated to create your > scheme. I've carefully read your message at least 4

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: >> I disagree with the last line above.  What makes you think that I'm >> presupposing that the tag does change? >> >> There's a difference between "presupposing that the tag does

Re: On raw strings in commit field

Hi Timothy, Am Samstag, dem 01.01.2022 um 12:45 -0500 schrieb Timothy Sample: > If you want a concrete example to think through, there’s ‘eclib’.  > Our package says it’s version “20190909”, but that’s not what > upstream calls version “20190909”.  It looks like when we packaged > ‘eclib’, that

Re: On raw strings in commit field

Hi all, Liliana Marie Prikler writes: > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: > >> If upstream later indicates that version "1.2.3" is now commit YYZ, I >> don't think that invalidates our basis for continuing to associate >> version "1.2.3" with commit XYZ.  The

Re: On raw strings in commit field

Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: > I disagree with the last line above.  What makes you think that I'm > presupposing that the tag does change? > > There's a difference between "presupposing that the tag does change" > and "not assuming that the tag will not

Re: On raw strings in commit field

> Where is the Cantor-style diagonalization argument that you spoke of? You skipped over it, read again. The key point is that you're referencing the thing you think will be invalidated to create your scheme.

Re: On raw strings in commit field

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

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver: [...] >> The simple fact is that the way Ricardo wrote the 'guile-aiscm' package >> is the right way to ensure that it can be reliably reproduced in the >> future. > And here I

Re: On raw strings in commit field

r 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"?

Re: On raw strings in commit field

Am Freitag, dem 31.12.2021 um 18:56 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > > Git commit hashes do not just depend on the content.  They also > > depend on how much effort you put into solving a proof of work > > challenge that won't ever earn you crypto

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Git commit hashes do not just depend on the content. They also depend > on how much effort you put into solving a proof of work challenge that > won't ever earn you crypto coins [1]. My knowledge of git is admittedly not that strong, but my

Re: On raw strings in commit field

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

Re: On raw strings in commit field

Hi, Am Freitag, dem 31.12.2021 um 18:21 +0100 schrieb zimoun: > Redundancy adds one kind of robustness: resilience.  [...]  However > this assumes all the redundant nodes of the web of nets will be still > up, at least enough to have this…  robustness.  Me too, I hope Guix > will be popular and

Re: On raw strings in commit field

On 2021-12-28, Liliana Marie Prikler wrote: > Consider a package being added or updated in Guix. At the time of > commit, we have the tag v1.2.3 pointing towards commit deadbeef. We > therefore create a guix package with version "1.2.3" pointing to said > commit (either directly or indirectly).

Re: On raw strings in commit field

Hi, On Fri, 31 Dec 2021 at 16:19, Liliana Marie Prikler wrote: > You're also missing the part in which it currently relies on a single > server to do all this, but there are plans to move it out to multiple > ones, i.e. adding fallbacks/redundancy to your fallback mechanism, > which for the

Re: On raw strings in commit field

Hi, Am Freitag, dem 31.12.2021 um 14:15 +0100 schrieb zimoun: > [...] > Version is also Guix specific.  Sometimes, we patch; for security > reasons, for fixing a bug, for quickly backporting something, for > removing non-free bits, for unbundling stuff, for making work with > the rest of Guix

Re: On raw strings in commit field

Hi all, On Fri, 31 Dec 2021 at 10:31, Ricardo Wurmus wrote: > I have no strong feelings for or against any of the proposed options. I > think that using raw commits might not be great for our tooling because > we’re not reusing an existing version string and would need to remember > to update

Re: On raw strings in commit field

Liliana Marie Prikler writes: > Particularly here, you're used to raw commit hashes, so you no longer > feel the need to add a comment explaining that it corresponds to a > given tag, which others (such as myself, your past self and possibly > your future self) would need at least until they

Re: On raw strings in commit field

Hi Ricardo, Am Freitag, dem 31.12.2021 um 10:31 +0100 schrieb Ricardo Wurmus: > In the past I’ve also added a comment above the raw commit, stating > that it corresponds to the given version. > > I have no strong feelings for or against any of the proposed > options.  I think that using raw

Re: On raw strings in commit field

Hi, Am Freitag, dem 31.12.2021 um 08:57 +0100 schrieb Taylan Kammer: > On 31.12.2021 04:15, Liliana Marie Prikler wrote: > >   [...] Obviously, > > when travelling back in time, we want Guix' "1.2.3" to be whatever > > it was by that point, but on

Re: On raw strings in commit field

Liliana Marie Prikler writes: >> And for completeness, let quote Ludo again from the same thread. :-) >> >>     No, I think we should consider always referring to commits >>     instead of tags.  It’s annoying from a readability viewpoint, >>     but it would ensure

Re: On raw strings in commit field

On 31.12.2021 04:15, Liliana Marie Prikler wrote: > [...] Obviously, when > travelling back in time, we want Guix' "1.2.3" to be whatever it was by > that point, but on the other hand, we also want a recently pulled Guix > to have a reasonably

Re: On raw strings in commit field

Hi, Am Freitag, dem 31.12.2021 um 02:23 +0100 schrieb zimoun: > Hi Liliana, > > I have read all your emails a couple of times and I am sorry I am > still missing what you are raising.  Because I feel we are failing to > explain each other, that’s fine, it happens sometimes :-) I hope > others

Re: On raw strings in commit field

Hi Mark, Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > It should be noted, that in the case of moving or deleted tags, the > > assertion Guix "1.2.3" = upstream "v1.2.3" no longer holds. > > Agreed, but I don't think that

Re: On raw strings in commit field

Hi Liliana, I have read all your emails a couple of times and I am sorry I am still missing what you are raising. Because I feel we are failing to explain each other, that’s fine, it happens sometimes :-) I hope others will find the intersection of this discussion. Honestly I am lost in the

Re: On raw strings in commit field

Am Donnerstag, dem 30.12.2021 um 13:43 +0100 schrieb zimoun: > Hi Liliana, > > On Wed, 29 Dec 2021 at 21:25, Liliana Marie Prikler > wrote: > > Am Mittwoch, dem 29.12.2021 um 09:39 +0100 schrieb zimoun: > > > On Tue, 28 Dec 2021 at 21:55, Liliana Marie Prikler > > > wrote: > > > The notion of

Re: On raw strings in commit field

Hi Mark, On Wed, 29 Dec 2021 at 20:13, Mark H Weaver wrote: > Guix packages that refer to git _tags_ may cease to be reproducible in > the future if upstream mutates or removes those tags, and it's simply > not feasible to transform our SHA256 hashes (of the NAR-encoded source > checkout) into

Re: On raw strings in commit field

Hi Liliana, On Wed, 29 Dec 2021 at 21:25, Liliana Marie Prikler wrote: > Am Mittwoch, dem 29.12.2021 um 09:39 +0100 schrieb zimoun: >> On Tue, 28 Dec 2021 at 21:55, Liliana Marie Prikler >> wrote: > The notion of equivalence I am using here is the same as in the > statement "5 ≡ 2 mod 3",

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > It should be noted, that in the case of moving or deleted tags, the > assertion Guix "1.2.3" = upstream "v1.2.3" no longer holds. Agreed, but I don't think that assertion should be our top priority. For purposes of Guix's core goal of enabling

Re: On raw strings in commit field

Hi, Am Mittwoch, dem 29.12.2021 um 09:39 +0100 schrieb zimoun: > Hi, > > On Tue, 28 Dec 2021 at 21:55, Liliana Marie Prikler > wrote: > > > Consider a package being added or updated in Guix.  At the time of > > commit, we have the tag v1.2.3 pointing towards commit deadbeef.  We > > therefore

Re: On raw strings in commit field

Hi, On Tue, 28 Dec 2021 at 21:55, Liliana Marie Prikler wrote: > Consider a package being added or updated in Guix. At the time of > commit, we have the tag v1.2.3 pointing towards commit deadbeef. We > therefore create a guix package with version "1.2.3" pointing to said > commit (either

On raw strings in commit field

Hi Guix, when Ricardo recently added guile-aiscm to Guix, I was confused that both the version field of the package and the commit field of the git- reference used in its origin. It turns out, that this is a rare pattern observed in less than 200 packages currently in Guix. The reason to do so