Right now if a computer were to have it's clock set for 2030, and it made commits and synced them, then with our hybrid logical clock we would always use that as the start date which would throw off the dates basically forever (or till 2030 in this example).
It's probably safe to say that the server will never get far out of sync, so we could just have the server reject commits from the future, 5 min in the future further more and it gets rejected?
However if we did that then a user would need some way to correct the dates on their commits so they could get back in sync. I'm not sure the best way to do that, and it could get complicated if you mix in offline sync, because those commits could have been sent somewhere else.
Right now if a computer were to have it's clock set for 2030, and it made commits and synced them, then with our hybrid logical clock we would always use that as the start date which would throw off the dates basically forever (or till 2030 in this example).
It's probably safe to say that the server will never get far out of sync, so we could just have the server reject commits from the future, 5 min in the future further more and it gets rejected?
However if we did that then a user would need some way to correct the dates on their commits so they could get back in sync. I'm not sure the best way to do that, and it could get complicated if you mix in offline sync, because those commits could have been sent somewhere else.