[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master cbef1e9 2/3: ; make change-history-commit

From: Glenn Morris
Subject: Re: master cbef1e9 2/3: ; make change-history-commit
Date: Sun, 12 Apr 2015 22:19:24 -0400
User-agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)

Paul Eggert 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 meant: I had assumed that the generated ChangeLog _information_ would
not be versioned now (did you really think I was asking about a file
literally named ChangeLog, and/or am unable to tell whether a file is in
the VCS or not?). One usually does not store generated files in the VCS,
as you know.

>> 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.

You seem to be conflating the old, written-by-hand ChangeLogs and the
new, generated ones. Obviously the old ones should not be removed from
VCS, that would be crazy and is not what I meant.

>> 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.

The file ChangeLog.1 in the repo contains a mixture of new, generated
entries applying to the entire Emacs tree, and (before a certain magic
date) older, hand-written entries that only apply to the top-level
(essentially) directory. I think it's pretty confusing to have both
things in the same file.

> 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.

That's not great, is it?
Suppose we improve/change the ChangeLog generation script, and want to
regenerate the generated ChangeLog. It will be difficult to extract the
various corrections that have been applied by hand to the generated

I had assumed that "ChangeLog" would be a top-level generated file that
would grow and grow with time, and would always be generated from
scratch whenever needed, with entries always starting from Apr 7 2015.

> effect, we have a hybrid approach, which uses Coreutils style for
> "recent" changelog entries and traditional Emacs style for "older"
> changelog entries.

Obviously, since we didn't want to throw away our old, hand-written
entries. This was a basic requirement and not some kind of selling

But I'm not going to do any work on this myself, so obviously I can't
expect anyone else to.

PS On a semi-related note, you renamed man/ChangeLog to ChangeLog.01
using the justification that erc/ already uses that system. But erc uses
a non-standard scheme where .YY contains the entries for 20YY. So
personally I think erc/ChangeLog.09 is incorrect, since it does not
contain entries for (just) 2009. IMO it would have been better to
combine all the old erc logs into erc/ChangeLog.1, and not to rename

reply via email to

[Prev in Thread] Current Thread [Next in Thread]