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: ChangeLogs in the elpa branch Date: Tue, 27 Sep 2011 03:10:42 -0400 Message-ID: References: <87ipofdbka.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1317107453 19607 80.91.229.12 (27 Sep 2011 07:10:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2011 07:10:53 +0000 (UTC) Cc: Michael Albinus , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 27 09:10:47 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R8RoV-00015s-AZ for ged-emacs-devel@m.gmane.org; Tue, 27 Sep 2011 09:10:47 +0200 Original-Received: from localhost ([::1]:38769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8RoU-0007Ds-NA for ged-emacs-devel@m.gmane.org; Tue, 27 Sep 2011 03:10:46 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8RoT-0007Dn-0P for emacs-devel@gnu.org; Tue, 27 Sep 2011 03:10:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8RoR-0008IN-Lc for emacs-devel@gnu.org; Tue, 27 Sep 2011 03:10:44 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:46631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8RoR-0008II-GB for emacs-devel@gnu.org; Tue, 27 Sep 2011 03:10:43 -0400 Original-Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1R8RoQ-0001Gp-7h; Tue, 27 Sep 2011 03:10:42 -0400 X-Spook: Yukon Downing Street Mossad Freeh Bush Wired lock picking X-Ran: pHEjT>\pcpk^Yx3P#3e.4Ew^8A9q~o779aH9;Lsm\0/gkBw=$1m)(=`(;39XR)T\E%7=b< X-Hue: blue X-Attribution: GM User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:144383 Archived-At: Stefan Monnier wrote: >> Reasons I object to getting rid of ChangeLogs: >> 1) Using Emacs VC, you only have to write the ChangeLog, then use C-c >> C-a to insert it into the commit buffer. So there is no need to "write >> the same thing twice". > > That doesn't seem like an objection but more like a reason why you're > willing to live with the duplication. OK. But much of the motivation to make the change seems to be "there will be less to type". I'm saying I don't find that compelling. I find the extra work involved in maintaining a ChangeLog to be worth it. (Did I miss some other reason why this change is desirable, beyond "somewhat fewer keypresses", and "slightly easier merging between branches"? CVS had both editable logs, and a cvs2log program, so what's changed? I guess it's that people tend to use more branches now, and find merging ChangeLogs difficult? As I said, try the changelog_merge plugin for that. Or don't keep (versioned) ChangeLogs in your personal branches.) >> 2) Sometimes I want to put more detail into the commit log, which is >> not appropriate for the ChangeLog. > > Without stating why, I can't assess how serious this is. It tends to be things like adding hrefs to emacs-devel discussions, or explaining more _why_ a change is needed as opposed to simply stating what the change was. >> 3) ChangeLogs can be edited to correct mistakes, commit logs cannot. > > That's not written in stone. CVS can edit its commit logs, and there's > no reason the same can't be done for other revision control systems. Shall we wait till bzr gets a good implementation of this feature then? > Better yet: there's no reason we can't do it ourselves in a (potentially > even backend-agnostic) way that will work for C-x v l and for > auto-generation of a ChangeLog file. This doesn't sound "better" to me. >> 4) I have the impression that having to write ChangeLogs leads to >> higher quality entries than just using commit logs would. > > I think this just reflects the better support in change-log-mode, with > highlighting, C-x 4 a and things like that. I disagree, I think people take more care with ChangeLogs.