From: Sergey Matveev <stargrave@stargrave.org>
Date: Sun, 22 Nov 2020 18:58:28 +0000 (+0300)
Subject: FAQ
X-Git-Tag: v0.2.0~6
X-Git-Url: http://www.git.cypherpunks.ru/?p=goredo.git;a=commitdiff_plain;h=bf61e9947b4f8240e9640472414c9751651de2fc

FAQ
---

diff --git a/README b/README
index f8b2873..d4d3876 100644
--- a/README
+++ b/README
@@ -66,8 +66,8 @@ COMMANDS                                               *goredo-commands*
   specified targets
 * redo-log -- display TAI64N timestamped last stderr of the target
 * redo-stamp -- record stamp dependency. Nothing more, just dummy
-* redo-cleanup -- removes either temporary, or log files, or
-  everything related to goredo
+* redo-cleanup -- removes either temporary, log files, or everything
+  related to goredo
 * redo-whichdo -- .do search paths for specified target (similar to
   apenwarr/redo): >
     $ redo-whichdo x/y/a.b.o
@@ -89,6 +89,51 @@ COMMANDS                                               *goredo-commands*
     $ redo-dot target [...] > whatever.dot
     $ dot -Tpng whatever.dot > whatever.png # possibly add -Gsplines=ortho
 <
+FAQ                                                         *goredo-faq*
+
+    Hashing and stamping~
+
+All targets are checksummed if their ctime differs from the previous
+ones. apenwarr/redo gives many reasons why every time checksumming is
+bad, but in my opinion in practice all of his reasons do not apply.
+
+* Aggregate targets and willing to be out-of-date ones just must not
+  produce empty output files. apenwarr/*, redo-c and goredo
+  implementations consider non existing file as an out-of-date target
+* If you really wish to produce an empty target file, just: touch $3
+
+DJB's proposal with both stdout and $3 gives that ability to control
+your desired behaviour. Those who does not capture stdout -- failed.
+Those who creates an empty file if no stdout was written -- failed.
+
+redo is a tool for helping people. Literally all targets can be safely
+"redo-stamp < $3"-ed, reducing false positive out-of-dates. Of course,
+with the correct working with stdout/$3 and placing necessary results in
+$3, instead of just silently feeding them in redo-stamp.
+
+redo implementations are already automatically records -ifchange on .do
+files and -ifcreate on non-existing .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.
+
+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.
+
+goredo includes redo-stamp, that really records the stamp in the .dep
+file, but it does not play any role later. It is stayed just for
+compatibility.
+
+    Removed .do can lead to permanent errors of its non existence~
+
+That is true, because dependency on it was recorded previously. Is it
+safe to assume that .do-less target now is an ordinary source-file? I
+have no confidence in such behaviour. So it is user's decision how to
+deal with it, probably it was just his inaccuracy mistake. If you really
+want to get rid of that dependency knowledge for foo/bar target, then
+just remove foo/.redo/bar.dep.
+
 STATE                                                     *goredo-state*
 
 Dependency and build state is kept inside .redo subdirectory in each