*** Karolis K [2021-11-20 21:18]:
>But I wonder - maybe it’s possible to somehow have this slow check be performed only once, and then updated?

Completely not sure if it should be done transparently and
automatically, but separate tool for that task is definitely
won't be a problem. I will look at it, when will got free time.

>It’s just hard for me to accept that after copying the project (or even renaming it with mv) it will be forever doomed to have a slow redo-ood return.

Not forever, but until the first rebuild/update. For me it is expectable
and acceptable behaviour, because... well, how can it be the other way?
I mean that reliable metainformation depends in practice on inode number
of similar things (apenwarr/redo does not depend on ctime, but on mtime
plus inode number and so on).

In goredo 1.21.0 you can use $REDO_INODE_TRUST=mtime if it is
acceptable (I believe in most cases in practice it is), so after even
now after copying (of course by keeping mtime) it won't fallback to hash
checking.

>Seems like this would negate a part of advantage that comes with having .redo/ info being stored within each directory separately.

I do not see any relation between our subject and .redo metainformation
placement. Main reason why .redo is stored in each directory: simplicity
and no problems with decision "where is the (projects) root?". Each
directory could be something isolated from another ones, unlike some
"central" database. For example apenwarr/redo admits that this is huge
pain to try to have single .redo (with sqlite3 database, in its case)
that is hard to determine where it should be placed.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF