On Wed, Jun 24, 2015 at 3:50 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> 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?
Because I don't want to have to do git log --format=fuller to see when
the thing was committed, basically.
>> 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.
I don't particularly think that having separate AuthorDate and
CommitterDate fields has any value. At least, it doesn't to me. But
a linear-looking commit history does have value to me. Someone else
might have different priorities; those are mine.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
