X-Git-Url: http://www.git.cypherpunks.ru/?p=goredo.git;a=blobdiff_plain;f=doc%2Ffaq.texi;h=1c6def3ffa8473be75a65b981e0d17f7b6514614;hp=02ea26b9872df96a5b33f5c3d6be25edda8be63c;hb=e2bafe8e0da716b4909da1b192d06c92c4f6260d;hpb=7450215ec9b548a3f883423da367cbeaa4186329

diff --git a/doc/faq.texi b/doc/faq.texi
index 02ea26b..1c6def3 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -5,9 +5,10 @@
 @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
@@ -18,26 +19,26 @@ apply.
 @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
@@ -56,8 +57,6 @@ then just remove @file{foo/.redo/bar.dep}.
 
 @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