Re: On making times=true the default

On Sun, 19 Jan 2025 at 14:56, Dan Christensen <[email protected]> wrote:
>
> On Jan 16, 2025, Greg Troxel <[email protected]> wrote:
>
> > So, I would be in favor of times=yes having automatic/silent conflict
> > resolution where the newer timestamp is set to the older one, as fixing
> > up past errors.
>
> I think it would be a mistake to auto-update times to the older one.  If

I don't know if that's what Greg meant, but my reading of his idea,
and my reply, was that this is just automatic conflict resolution, not
automatic propagation (which I would not support). In other words,
there would first have to be a conflict of times changed on both sides
(and no other changes), only then the propagation direction is
automatically proposed to the user. User's manual actions or
preferences could still override that.

Ideally, this kind of conflict resolution would only need to happen
during version upgrade.

> For example, make's behaviour depends on timestamps.  Suppose we have
> file1.c producing file1.o, with the replicas in sync (including times).
>
> I edit file1.c and rebuild file1.o, but then realize that there's a bug.
> So I revert my change to file1.c, but don't get around to running make.
> Then I run unison, and the timestamp on file1.c gets set to the old
> time, since the file contents match.  Then I run make, and file1.o is
> *not* updated, and I can't figure out why the program is still buggy.

This is not the proposal (well, at least my reading of Greg's idea).
In your example there would be no conflict as the time has changed
only in one replica. Quite the opposite, the new timestamp of the
reverted file1.c would be propagated to update the older one. Just as
you'd expect.