On Wed, Jun 24, 2015 at 11:37 AM, Peter Eisentraut <pete...@gmx.net> wrote: > 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.
I don't, because it means that the timestamps you see when you run git log are non-linear. I don't care myself if they are slightly out of order, although it seems that others do, but I do mind when they are months off. Typically when this happens to me, it's not a case of the patch being unchanged. I make changes on a branch and then use git rebase -i to squash them into a single patch which I then cherry-pick. But git rebase -i keeps the timestamp of the first (oldest) commit, so I end up with a commit that is timestamped as to when I began development, not when I finished it. So the date is just wrong. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers