the disk. You can disable its usage with @env{$REDO_NO_SYNC=1}
environment variable, for speeding up the build process.
-@command{goredo} determines target is out-of-date by comparing its size,
-@code{ctime} and content's hash, if @code{ctime} differs. Depending on
-the filesystem you use, probably you can not trust its @code{ctime}
-value at all. In that case you can set @env{$REDO_INODE_NO_TRUST=1} to
-forcefully verify the hash.
+If redo sees some target modified externally, then by default it warns
+user about that, does not build that target, but continues the build
+process further. That is convenient in most cases: you can build your
+project with manual targets alterings, without touching possibly more
+complicated @file{.do} files. With @env{$REDO_STOP_IF_MODIFIED=1} redo
+won't continue and will exit with failure message.
There are other commands that could be found in other implementations too:
@item redo-cleanup
Removes either temporary (@option{tmp}), log files (@option{log}),
or everything related to @command{goredo} (@option{full}).
+
@item redo-whichdo
Display @file{.do} search paths for specified target (similar to
@command{apenwarr/redo}):
../default.o.do
../default.do
@end example
+
@item redo-dot
Dependency
@url{https://en.wikipedia.org/wiki/DOT_(graph_description_language), DOT}
$ dot -Tpng whatever.dot > whatever.png # possibly add -Gsplines=ortho
@end example
+@item redo-depfix
+ When you copy your worktree to different place, then copied files
+ ctime will change. And because recorded dependency information
+ differs from updated ctimes, out-of-date algorithm will fallback to
+ rereading the whole files for hash calculation, that is much slower.
+ If you do not want to rebuild your targets from the ground, then
+ @command{redo-depfix} can traverse through all dependency files and
+ check if they have non-altered ctime values and update them in place.
+
@end table