Greetings!

*** Niklas Böhm [2025-12-05 19:30]:
>file `1` already exists (or you remove the folder `.redo/`), then the call
>to `redo 1` throws the following error:
>
>err  1 (0.001s): $1 was explicitly touched

That message is misleading indeed. Fixed in 2.7.0 release. Now it will
print "already existing".

>I think that this is a bug (most probably related to run.go l.674 or so) and
>the behavior should be to either (a) detect it as a source file and not redo
>it (the behavior if the file `1.do` did not exist) or (b) redo the target
>properly.  I strongly prefer option (a), as we should not mess with a file
>that we do not know the origin of.

I completely agree that (b) is not acceptable: we must not touch files
which we do not created. But I doubt (a), treating it like a source
file, is a good option too: how we differentiate and understand was it
accidentally created or user does not notice its existence with the
corresponding .do?

*** spacefrogg-goredo [2025-12-05 20:26]:
>Yes, that is a bug.
>You can observe the correct behaviour when you change `1.do` to `default.do`, which is:
>- after deleting `.redo/` `redo 1` prints nothing anymore, because it treats the file as a source file. You can verify by setting REDO_DEBUG=1.

That is very good point! Of course existence of default.do-s should be
treated like a presence of the .do. goredo checked if source file is a
source just by checking the nearby $1.do existence.

I think that "source file" is a file which does not have build
instructions (corresponding .do file). So we should use the same logic
of do-files searching for the consistency of the behaviour. If we find a
.do file, the presence of already existing target and lack of its
information in .redo-state, then we should warn user about already
existing target. But, just like in the case of "externally modified"
one, continue the redo process without raising an error, not touching
that target's file.

I brought those changes (proper check of .do existence and a
non-misleading warning message) in the 2.7.0 release. But that also
leads to inability to have multiple default.*.do together with
default.do. As every file, including do-file itself, can be build by
redo itself, it has to be checked the same way as every other ones.
Having default.do will lead to treating it like a do-file for the
default.*.do nearby. But that should be the expected behaviour.
Otherwise how can be distinguish autogenerated do-files from
mistakenly left.

-- 
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A