|
From: | Daniel J Sebald |
Subject: | Re: ChangeLogs |
Date: | Mon, 05 Jan 2009 23:13:36 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
Jaroslav Hajek wrote:
On Mon, Jan 5, 2009 at 5:32 PM, John W. Eaton <address@hidden> wrote:On 5-Jan-2009, Jaroslav Hajek wrote: | Applied. Thanks for applying this change. It still seems confusing to me that you leave the ChangeLog entry alone when applying patches. If I do "hg log" now, I see changeset: 8444:c3ac9f2772cd tag: tip user: Thorsten Meyer <address@hidden> date: Mon Jan 05 10:54:22 2009 +0100 summary: do not eat white space within @example environments of docstrings at the top, but the ChangeLog entry for this change does not have a Jan 5 date. Instead, it has a 2008-11-07 date. If I were looking at this ChangeLog entry and wanted to find the corresponding changeset, the date for the ChangeLog entry would not help me find the changeset. This is why I think we should revise the date of the ChangeLog entry when checking in changes so that new ChangeLog entries should always appear at the top of the ChangeLog file.Sorry, I didn't notice the changelog entry didn't go on top of the file. I do agree that it always should. We should note this in contrib.txi. Mea culpa.
This is the one disadvantage of putting ChangeLog hunks in the patch file. They are almost always rejected because some other entry has already been placed at the top. Anyone know of a command line switch to make diff force the hunk to be at the top when patched? The patch date should be the date the patch was applied, not the date it was created, in my opinion.
Or, we should simply decide to do away with ChangeLog files entirely. But if we do that, I think we should put much more complete commit messages in the mercurial log files, and we should agree on a common style for the commit messages.
A few nice things about ChangeLogs: 1) Legacy and consistency across projects. I go from one bundled program to the next and see ChangeLog, INSTALL, README, and I almost immediately know what to do. 2) ChangeLog can be quickly grepped or searched. Can source control log entries be searched as quickly? 3) Contributors who don't check in stuff can place a ChangeLog entry as a hunk in the patch file. Dan
[Prev in Thread] | Current Thread | [Next in Thread] |