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.