On 6/12/15 9:31 AM, Robert Haas wrote: > Could we update our git hook to refuse a push of a new commit whose > timestamp is more than, say, 24 hours in the past? Our commit history > has some timestamps in it now that are over a month off, and it's > really easy to do, because when you rebase a commit, it keeps the old > timestamp. If you then merge or cherry-pick that into an official > branch rather than patch + commit, you end up with this problem unless > you are careful to fix it by hand. It would be nice to prevent > further mistakes of this sort, as they create confusion.
FWIW, I have been doing that, and I have not considered it a problem. If the patch was submitted three months ago, reviewed, and then committed unchanged, the date is what it is. Also, when I cherry-pick a commit from master to a back branch, I keep the author timestamp the same. I consider that a feature. Note that we have a while ago enabled author and committer to be distinct. But the above proposal would effectively require author date and committer date to be (almost) the same, which would create inconsistent information. Also, rebasing updates the committer date but not the author date, because, well, the commit was changed, but no authoring is involved. git rebase has options to vary this behavior, but note that the documentation uses the term "lie" in their description. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
