Hi, On Fri, 15 Jul 2016 18:03:30 +0000 Robin H. Johnson wrote: > Hi all, > > In tracing down problems with the git->rsync path, it has been noticed > that some developers have significant clock drift on their local systems > (up to one case of 14 days wrong), and it's potentially contributing to > problems in generating the rsync tree. > > I have implemented a check as part of the hook that validates Git push > certificates (require-signed-push). It looks for clock drift or an > overly long push, and aborts if needed. > > The tolerances are presently set to: > - 5 seconds of clock drift.
Why such tight requirement? Why not a minute, which will not hurt git, but will help with system _temporarily_ out-of-sync. Some hardware clocks are real mess and can drift more that for 5 seconds in a few days (e.g. when system was shut down). And for NTP it will take time to correct system clock _properly_. While stuff like running ntpdate before ntp server if system is out of sync is possible, but it is not recommended nor possible on some workloads. So IRL NTP may take several hours to sync system properly. Set it for a minute or two. This will protect from commits from really out-of-sync systems (like 14 days mentioned above) and will keep usablity hight for others. > - 'git push' must be completed in 60 seconds. Why?! What is wrong if push will take 120 seconds? I often commit from quite an old box and git push takes 20-40 seconds, while this is within your limits, the margin is not safe. What if someone needs to commit via 2G GPRS or similar slow network link? Afaik we have developers on quite slow and unstable links. Just set this limit to 5 minutes to make it a sane protection of a stale push. Best regards, Andrew Savchenko
pgpfpQXlwFk3S.pgp
Description: PGP signature
