Re: ChangeLogs in commit messages

[James Hogan <james.hogan@imgtec.com>]

On 08/09/14 10:50, Gary Benson wrote:
> Doug Evans wrote:
>> On Fri, Sep 5, 2014 at 3:13 AM, Gary Benson <gbenson@redhat.com> wrote:
>>> Gary Benson wrote:
>>>> Doug Evans wrote:
>>>>> If I do a git blame of server.c I see patch 860789c7 with a
>>>>> date of 2014-08-08.  That's three weeks before it was pushed
>>>>> upstream.  Bleah.  I'd really like to be able to do a git
>>>>> blame and have what I see be useful, including the date.  The
>>>>> author date is basically useless to me.
>>>>
>>>> I see some options to git-rebase, --committer-date-is-author-date
>>>> and --ignore-date.  I'll experiment with these the next time I
>>>> rebase something and see what happens.
>>>
>>> Running "git rebase --ignore-date gdb/master" immediately prior to
>>> pushing sets both author and commit dates to the present time on
>>> all commits you are about to push.
>>
>> Cool.  Can you add that to the contribution checklist?
> 
> https://sourceware.org/gdb/wiki/ContributionChecklist#Fixing_commit_dates
> 
> If we add a server-side hook to check that the ChangeLog messages in
> the commit messages are correct we could also use that hook to check
> that the dates in commits match the dates in the ChangeLog files.

IMHO this is a really bad idea.

You're suggesting discarding/falsifying genuine information (the
authorship dates) from the git history for no good reason since the
information you want to store is already there in the commit date.

1) "the commit dates are wrong". you probably mean the author dates are
unchanged, since the committer dates get reset by default whenever a
commit is recommitted (written, i.e. commit --amend, rebased, cherry
picked etc).

2) The commit date should reflect roughly what you want already. You
need to rebase if anybody else has pushed to the branch in order to keep
the history linear anyway which will reset the committer dates, which
also means they'll be in order as you'd expect.

The author date is supposed to reflect when the patch was authored, not
when it was committed/pushed (or in the case of git-send-email/git-am
it's the date it was sent to the mailing list).

FYI it allows you to:
* get information about author's habits (what hours they usually work)
and timezone, and when they were active in the project, separate from
the committer. E.g. github shows this information in it's contributions
section for each user, organised by day of the week.
* gives you a better idea of the real age of the patch.
* make it easier to distinguish which version of a patch was applied and
find it in the mailing list archives.
* allows you to see more easily how quickly patches are getting upstream

And all that regardless of whether it has been cherry picked onto a
stable branch at a later date, maybe even after the author has moved on
to other things (cherry-picking usually only changes the commit date).

Cheers
James