X-Git-Url: http://www.git.cypherpunks.ru/?p=goredo.git;a=blobdiff_plain;f=README;h=d49c3cc020e7ef506840eb72492e68cd031f617e;hp=222c94ae2ba99c09a29fd60e05393b6a1757338c;hb=6b1228a8f2c83bf1f7c74fe6405a0bf84f885896;hpb=448a8aebeac3a5c411a500f65941bb3c3f90758a

diff --git a/README b/README
index 222c94a..d49c3cc 100644
--- a/README
+++ b/README
@@ -25,7 +25,7 @@ problems with the authenticity on your side, then build it manually: >
 
     $ git clone git://git.cypherpunks.ru/goredo.git
     $ cd goredo
-    $ git tag -v v0.4.1
+    $ git tag -v v0.5.0
     $ git clone git://git.cypherpunks.ru/gorecfile.git
     $ ( cd gorecfile ; git tag -v v0.3.0 )
     $ echo "replace go.cypherpunks.ru/recfile => `pwd`/gorecfile" >> go.mod
@@ -138,14 +138,33 @@ 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.
+    Can removed .do lead to permanent errors of its non existence?~
+
+Yes, 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.
+
+    Does redo-always always rebuilds target?~
+
+goredo, together with apenwarr/redo, rebuilds target once per run.
+Always rebuilds during every redo invocation, but only once during it
+building. http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice
+has other opinion, that is why its 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 .h file contains source code's version number, that is
+git-describe's output and all my other files depends on that header,
+then any redo-ifchange of .o will lead to git-describe execution, that
+is rather heavy. Of course, because of either hashing or possible
+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 redo-sh's FAQ) until all references and numbers are ready,
+then you must simply explicitly use while cycle in your .do, as
+apenwarr/redo already suggests.
 
 STATE                                                     *goredo-state*