From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Glenn Morris Newsgroups: gmane.emacs.devel Subject: Re: master cbef1e9 2/3: ; make change-history-commit Date: Sun, 12 Apr 2015 22:19:24 -0400 Message-ID: References: <20150409172246.20602.44549@vcs.savannah.gnu.org> <5526E084.4060403@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1428891573 20552 80.91.229.3 (13 Apr 2015 02:19:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Apr 2015 02:19:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 13 04:19:33 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YhTyF-0007Tu-RD for ged-emacs-devel@m.gmane.org; Mon, 13 Apr 2015 04:19:31 +0200 Original-Received: from localhost ([::1]:46789 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhTyF-0001am-1E for ged-emacs-devel@m.gmane.org; Sun, 12 Apr 2015 22:19:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhTyB-0001ah-Ew for emacs-devel@gnu.org; Sun, 12 Apr 2015 22:19:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YhTyA-0004vK-8F for emacs-devel@gnu.org; Sun, 12 Apr 2015 22:19:27 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YhTyA-0004vG-4h for emacs-devel@gnu.org; Sun, 12 Apr 2015 22:19:26 -0400 Original-Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1YhTy8-0002tb-AC; Sun, 12 Apr 2015 22:19:24 -0400 X-Spook: cryptographic Serbian lock picking Marxist smuggle X-Ran: 23Uu:\/)ogZn>'pCa\[GI9P\[eOFXFjL?e[p1\L#^>>{2?,KtE>VB1Nu{ (Paul Eggert's message of "Thu, 09 Apr 2015 13:26:44 -0700") User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185365 Archived-At: 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 entries. 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 point. 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 man/ChangeLog.