On Wed, Jun 24, 2015 at 11:37 AM, Peter Eisentraut <peter_e@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
