Re: git push hook to check for outdated timestamps

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: git push hook to check for outdated timestamps
Date: 2015-06-24 19:50:00
Message-ID: 558B09E8.6070000@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/24/15 12:55 PM, Robert Haas wrote:
>> 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.

Why is that a problem?

> 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.

Sure, but then it's up to you to fix it, just like it's up to you to
merge the commit messages and do other adjustments to the commit. But
this is one of many cases, and we shouldn't throw out the whole concept
because of it.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-06-24 19:56:21 Re: pg_stat_*_columns?
Previous Message Andres Freund 2015-06-24 19:49:51 Re: Should we back-patch SSL renegotiation fixes?