Re: git push hook to check for outdated timestamps
От | Noah Misch |
---|---|
Тема | Re: git push hook to check for outdated timestamps |
Дата | |
Msg-id | 20150625041911.GD603717@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: git push hook to check for outdated timestamps (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Jun 24, 2015 at 10:03:50AM -0400, Robert Haas wrote: > On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch <noah@leadboat.com> wrote: > >> That brings it back to the enforcing - would we want to enforce both those? > > > > May as well. AuthorDate is the main source of trouble. You would need to go > > out of your way (e.g. git filter-branch) to push an old CommitDate, but let's > > check it just the same. > > Actually, you just need the system clock to be off. I've noticed, for > example, that when my VMware VMs go to sleep (because I close my > laptop lid) their clocks don't run, so I have to remember to ntpdate > afterwards if I want correct time. I don't happen to use those for > committing to PostgreSQL, but somebody else might have a similar setup > that they do use for that purpose. I didn't think of that. So, yep, checking both is valuable. > So +1 for sanity-checking the commit date, and +1 as well as Alvaro's > proposal for checking for both past and future times. I think we > should tolerate a bit more in terms of past timestamps than future > timestamps. It's quite reasonable for someone to commit locally and > then run make check-world or so before pushing; let's not make that > unnecessarily annoying. But future timestamps should really only ever > happen because of clock slew, and I don't think we need to tolerate > very much of that. Sounds good.
В списке pgsql-hackers по дате отправления: