@section Hashing and stamping
All targets are checksummed if their @file{ctime} differs from the
-previous one. @command{apenwarr/redo} gives many reasons why every time
-checksumming is bad, but in my opinion in practice all of them do not
-apply.
+previous one. @command{apenwarr/redo} gives
+@url{https://redo.readthedocs.io/en/latest/FAQImpl/#why-not-always-use-checksum-based-dependencies-instead-of-timestamps, many reasons}
+why every time checksumming is bad, but in my opinion in practice all of
+them do not apply.
@itemize
@item Aggregate targets and willing to be out-of-date ones just must not
@end itemize
DJB's proposal with both @file{stdout} and @file{$3} gives that ability
-to control your desired behaviour. Those who does not capture
-@file{stdout} -- failed. Those who creates an empty file if no
+to control your desired behaviour. Those who do not capture
+@file{stdout} -- failed. Those who create an empty file if no
@file{stdout} was written -- failed.
redo is a tool to help people. Literally all targets can be safely
@code{redo-stamp < $3}-ed, reducing false positive out-of-dates. Of
course, with the correct @file{stdout}/@file{$3} working and placing
necessary results in @file{$3}, instead of just silently feeding them in
-redo-stamp.
+@command{redo-stamp}.
redo implementations are already automatically record -ifchange on
@file{.do} files and -ifcreate on non-existing @file{.do} files. So why
-they can not record redo-stamp the same way implicitly? No, Zen of
-Python does not applicable there, because -ifchange/-ifcreate contradict
-it already.
+they can not record @command{redo-stamp} the same way implicitly? No,
+Zen of Python does not applicable there, because -ifchange/-ifcreate
+contradict it already.
Modern cryptographic hash algorithms and CPUs are so fast, that even all
read and writes to or from hard drive arrays can be easily checksummed
-and transparently compressed, as ZFS with LZ4 and Skein/BLAKE[23]
-algorithms demonstrate us.
+and transparently compressed, as ZFS with LZ4/Zstandard and
+Skein/BLAKE[23] algorithms demonstrate us.
@command{goredo} includes @command{redo-stamp}, that really records the
stamp in the @file{.dep} file, but it does not play any role later. It
@command{goredo}, together with @command{apenwarr/redo}, rebuilds target
once per @strong{run}.
-Always rebuilds during every redo invocation, but only once during it
-building.
@url{http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice, redo-sh}
has other opinion, that is why its @file{redo-sh.tests/always_rebuild_1}
will fail. Rebuilding of always-ed targets even during the same build