Feature Request: Timestamp first mode

[JC-comp]

Is your feature request related to a problem? Please describe.

Currently, only one of the remote or local fisrt mode is supported. That is, if the remote first mode is selected, all data not in sync will be replaced locally. Conversely, if the local first mode is chosen, all online data will be replaced. The impact is minor in monitor mode, where changes are synced and reflected instantly. However, for a new sync or re-sync after a time gap, it would be more suitable to keep the latest version among the remote and local versions based on the last modified timestamp. This is especially important in cases where changes could occur on both sides, as it is not necessary for one side to always replace the other.

Describe the solution you'd like

Option to use time as the primary criterion to determine which side should replace the other, with the additional choice to specify remote or local as the fallback when time is unavailable to make a decision.

Describe alternatives you've considered

Additional context

No response

[abraunegg]

@JC-comp

Option to use time as the primary criterion to determine which side should replace the other

Regardless of mode of operation today, timestamps are already the primary method of comparison, and depending on which mode of use, depends on what is kept or replaced. The secondary (the hash) is only looked at and computed if the timestamps are different.

As per previous ask, please communicate with me offline via email.

[abraunegg]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.