public inbox for goredo-devel@lists.stargrave.org
Atom feed

From: Sergey Matveev <stargrave@stargrave•org>
To: goredo-devel@lists.cypherpunks.su
Subject: Re: redo-stamp
Date: Wed, 2 Apr 2025 10:45:51 +0300	[thread overview]
Message-ID: <Z-zrL8eIWhzZie42@stargrave.org> (raw)
In-Reply-To: <Z+rXvAidoqlz4p5L@xerus.org>

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

Greetings!

*** Christian G. Warden [2025-03-31 12:58]:
>I can of course generate `date` and `user` files rather than use
>redo-stamp, but is there any reason to intentionally not support this
>functionality?  Any other suggestions?

Your case with the date.do can (and should) be easily made solely by
honestly generating the "date" file:

    data.csv.do:
        redo-ifchange date
        ... fetch data > $3

    date.do:
        redo-always
        date +%Y%m%d

That works in goredo as expected. redo-ifchange means "redo that given
target (data.csv) if date-file is changed". "date | redo-stamp" does not
lead to changing the contents of "date" file, as its stdout was empty.

As far as I remember, redo-stamp is just a hack to skip checksum/hash
computation of the file to determine if it is really changed.
apenwarr/redo thinks that "date" is changed if its inode's
metainformation (some of its fields) is altered, without checking if its
contents are still the same (unless redo-stamp was used of course).
Unlike apenwarr/redo, goredo always checks its contents (by comparing
cryptographic hash) if inode if altered.

You can treat default goredo's behaviour as "always feeding target's
output to redo-stamp". apenwarr/redo redo-stamp's it only if explicitly
asked for. I assume that:

    date.do:
        redo-always
        date +%Y%m%d >$3
        redo-stamp <$3

will work the same expected way both in apenwarr/redo and in goredo.
I am convinced that redo-stamp was just a hack to skip relatively
expensive SHA1 computation. And that hack should not exist at all.
It adds unnecessary complications to the out-of-date decision code.
redo-stamp command was left in goredo only to be able to write targets
that have to have redo-stamp-hack and be run under apenwarr/redo too.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

next prev parent reply	other threads:[~2025-04-02  7:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31 17:58 redo-stamp Christian G. Warden
2025-04-02  7:45 ` Sergey Matveev [this message]
2025-04-02 10:54   ` redo-stamp spacefrogg
2025-04-03 22:45     ` redo-stamp Andrew Chambers
  -- strict thread matches above, loose matches on Subject: below --
2021-10-27 17:18 Multiple calls to redo-* for same target results in multiple .rec entries goredo
2021-10-31  8:21 ` Sergey Matveev
2021-11-04 15:35   ` goredo
2021-11-09  9:13     ` Sergey Matveev
2021-11-09 13:43       ` goredo
2021-11-10 12:22         ` redo-stamp Sergey Matveev