Subject: Re: Suggestion to revert touching files when the hash matches (problem with hardlinks)

From: Spacefrogg <[email-masked]>
Date: Tue, 1 Nov 2022 12:49:59 +0100 (GMT+01:00)

>     a: inode=646, mtime=1667292427
>     b: inode=646, mtime=1667292427

Your bug is right here. This is a misuse of redo and breaks its logic. A and B are expected to mean different things, so they MUST NOT point to the same inode. Period.

>     a: inode=655, mtime=1667292646
>     b: inode=655, mtime=1667292646  # wasn't redone, but changed

This is, where you trigger the bug. Yes, reverting goredo resolves this exact TRIGGER of the bug. Your actual bug is still present, see above.

I reiterate: Separate paths MUST represent separate inodes or you break redo logic one way or another.

Your bug has nothing to do with the change in 1.23. I don't see why your case of misusing redo should be given any preference over a completely useful optimisation that is in line with the logic of redo.

One way out of your mess is that you create a c.do with an indirect dependency:
redo-ifchange a
ln a b # indirect dependency
touch $3

Users have to depend on c and know that they should use b. Now, you are honest to your consumers, that b is some dirty optimisation that may/will be changed whenever a is changed.

Final words: I sympathize with what you are trying to achieve. But you should rather fix the bug instead of removing one of its triggers.

Kind regards,
–Michael