On Wed, Jun 24, 2015 at 3:50 PM, Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers