@anchor{Stamping}
@section Hashing and stamping
-All targets are checksummed if their @file{ctime} differs from the
-previous one. @command{apenwarr/redo} gives
+All targets are checksummed if target's @file{ctime} differs from the
+previous one, or @env{REDO_INODE_NO_TRUST} environment variable is set.
+@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.
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
+stamp in the @file{.rec} file, but it does not play any role later. It
is stayed just for compatibility.
@section Can removed .do lead to permanent errors of its non existence?
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 @file{foo/bar} target,
-then just remove @file{foo/.redo/bar.dep}.
+then just remove @file{foo/.redo/bar.rec}.
@section Does redo-always always rebuilds target?
-@command{goredo}, together with @command{apenwarr/redo}, rebuilds target
-once per @strong{run}.
-@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
-process ruins any redo's usability in practice.
-
-For example if my @file{.h} file contains source code's version number,
-that is @command{git describe}'s output and all my other files depends
-on that header, then any @command{redo-ifchange} of @file{.o} will lead
-to @command{git describe} execution, that is rather heavy. Of course,
-because of either hashing or possible @command{redo-stamp}-ing its
-dependants won't be rebuilt further, but build time will be already
-ruined. If you need to rebuild TeX documents (case mentioned in
+By definition, it should be build always, as
+@url{http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice,
+redo-sh} and @command{redo-c} implementations do. But that ruins the
+whole redo usability, potentially rebuilding everything again and again.
+@command{apenwarr/redo} and @command{goredo} tries to build
+always-targets only once per @strong{run}, as a some kind of optimization.
+
+For example if you need to rebuild TeX documents (case mentioned in
redo-sh's FAQ) until all references and numbers are ready, then you must
naturally expectedly explicitly use while cycle in your @file{.do}, as
@command{apenwarr/redo} already suggests.
+
+@section What to do with OOD targets, that has not changed their output?
+
+How to prevent building of targets, who depend on the OOD target, that
+produced the same output? If the target is already decided to be OOD,
+then the whole tree becomes OOD too. It is clear, simple, reliable and
+honest way of do-ing things.
+
+Building of the lower level OOD target first is unfair and dishonest
+thing to do, because probably top level target, being the OOD, won't be
+dependant on lower level target anymore at all. Actually @command{goredo}
+does this as a shameful hack and only for always-targets, still existing
+in the wild. The whole @command{redo-always} idea is wrong.
+
+If you wish to run something and decide if it must OOD the toplevel
+targets, then just run @command{redo} to forcefully rebuild it and then
+run the ordinary top level targets.