public inbox for goredo-devel@lists.stargrave.org
Atom feed
From: spacefrogg <spacefrogg-goredo@spacefrogg•net>
To: goredo-devel@lists.cypherpunks.su
Subject: Re: redo-stamp
Date: Wed, 02 Apr 2025 12:54:39 +0200 [thread overview]
Message-ID: <0bf3303ce7d3ad03a9167a789bded3cf@spacefrogg.net> (raw)
In-Reply-To: <Z-zrL8eIWhzZie42@stargrave.org>
I agree with Sergey's assessment.
> 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.
I want to add one thing, though. `redo-stamp` does add one small
convenience.
It allows you to create the hash over *some* data that describes the
identity of your target,
while using the original output for further computation. This makes
working with noisy data
more convenient (e.g. time stamped). But I grant you that this is a
small convenience
with the potential of confusing tool chain users down the line.
–Michael
next prev parent reply other threads:[~2025-04-02 11:21 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 ` redo-stamp Sergey Matveev
2025-04-02 10:54 ` spacefrogg [this message]
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