[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: master cbef1e9 2/3: ; make change-history-commit
From: |
Paul Eggert |
Subject: |
Re: master cbef1e9 2/3: ; make change-history-commit |
Date: |
Thu, 09 Apr 2015 13:26:44 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
On 04/09/2015 11:24 AM, Glenn Morris wrote:
I had assumed that the ChangeLog would not be versioned at all now,
but it seems like it is?
No, your assumption is correct. For example, there is no ChangeLog here:
http://git.savannah.gnu.org/cgit/emacs.git/tree/ChangeLog
I assumed that only the corrections would be versioned, and the full
file would only appear in tarballs as a generated file.
Stefan indicated long ago that this was too drastic, and that we should
keep ChangeLog history files in the repository, e.g., lisp/ChangeLog.10
is still in the repository and hasn't changed since January 1's
copyright-date edits. ChangeLog.1 is another file like
lisp/ChangeLog.10; i.e., it's another versioned ChangeLog history file
that you can edit by hand whenever you like.
I further assumed that the new-style generated log would always be
separate from the old-style ChangeLog.1
Yes, that's correct. The ChangeLog file in the tarball (built by 'make
ChangeLog') is disjoint from ChangeLog.1, in that ChangeLog.1 contains
only "older" entries and Changelog contains only "newer" entries.
(I thought this was why the
latter was renamed to ChangeLog.1), but it seems like you added new
entries to ChangeLog.1?
Yes, the idea is that you can move the boundary line between "older" and
"newer" by running "make change-history". This automated procedure
moves the boundary to be the present, and hence entries that until now
would have been put into ChangeLog, are put into ChangeLog.1 and become
part of the manually-edited history, which means that ChangeLog will
become empty. This is how you can fix old ChangeLog entries: run "make
change-history", then edit ChangeLog.1 by hand and commit the result.
The advantage of this approach over the old Emacs approach, is that
ordinary commits won't alter any ChangeLog files, which will make merge
collisions less common. (RMS's recent problem, for example, would have
not occurred.) And the advantage of this approach over the approach
taken by Coreutils, Grep, etc. (which do not store ChangeLogs in the
repository) is that it's easier to edit history by hand. In effect, we
have a hybrid approach, which uses Coreutils style for "recent"
changelog entries and traditional Emacs style for "older" changelog entries.
Re: master cbef1e9 2/3: ; make change-history-commit, Robin Templeton, 2015/04/09